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The  Navy's  strong  commitnient  to  CALS  is  reinforced  by  the  significant  process 
and  productivity  that  CALS  initiatives  are  providing  within  the  Navy 
infrastructure.  CALS  programs  are  on-line  and  working  In  today's  Navy  to 
produce  improved  weapons  system  designs,  access  more  accurate  and  timely 
technical  data,  and  reduce  acquisition  and  logistics  support  costs. 

In  an  era  of  declining  budgets,  CALS  is  most  important  in  enhancing  logistic 
support  productivity  to  maintain  operations  and  improve  readiness.  Our 
continued  emphasis  is  on  coordinating  and  further  integrating  CALS  initiatives 
across  the  entire  life  cycle  of  technical  data  to  achieve  the  synergy  inherent  in  a 
network  of  distributed  data' 

J.B.  Greene,  Jr. 

Rear  Admiral,  US  Navy 

Extracted  from  Rear  Admiral  Green's  Welcome  to  CALS  Expo  '91  in  the 
Navy  CALS  Expo  '91  Brochure 


Computer-aided  Acquisition  and  Logistic  Support  (CALS)  is  becoming  a  very  important 
part  of  the  Navy's  business  approach.  The  intent  of  CALS  is  to  improve  the  timeliness, 
reduce  the  costs,  and  improve  the  quality  of  defense  system  acquisition  and  support 
This  goal  is  to  be  accomplished  through  the  general  adoption  of  a  set  of  procedures 
and  standards  for  the  production,  access,  management  maintenance,  and  distribution 
of  technical  data  in  digital  form./  This  goal  will  enj  Jle  more  effective  creation, 
exchange,  and  use  of  data  for  defense  systems  and  equipment.  The  first  part  of 
CALS,  now  being  implemented,  is  focusing  on  phasing  out  paper  document  transfer 
where  feasible,  in  favor  of  electronic  file  exchanges.  A  longer-term  CALS  ot^ective  is 
to  develop  integrated  product  data  bases  and  create  advanced  engineering  and 
manufacturing  systems.  The  approach  to  CALS  implementation  will  vary  by  program 
acquisition  phase  and  by  program  type,  size  and  dur^on. 

This  Navy/Marine  Corps  Manager's  Desktop  Guide  foi  CALS  Implementation  compiles 
numerous  specifications,  manuals,  and  documents  pertaining  to  CALS  and  the 
acquisition  of  digital  technical  data  This  guide  contains  both  background  and  working 
information  about  the  use  of  CALS  in  the  acquisition  process.  It  also  provides  a 
compilation  of  the  Navy's  direction  and  intent  for  the  incorporation  of  CALS  into 
defense  system  programs.  Also  included  (Figure  Intro-1)  is  a  model  for  the  Naval 
forces  perspective  of  'CALS  in  the  Acquisition  Process.'  This  model  is  included  as  a 
graphic  on  the  cover  of  each  document  section  with  the  relevant  section  highlighted 
within  the  process  model.  The  intent  of  this  Acquisition  Process  Model  and  this 
Desktop  Guide  is  to  assist  you  in  providing  synergy  among  CALS,  the  acquisition 
process,  and  the  Navy's  commitment  to  improving  business  processes.  \  j ,  , . 

Forturther  questions,  comments,  or  recommendations  on  this  guide,  write  or  call 

CALS  Resource  and  Inplementation  Cooperative  (RIC) 

Naval  Air  Warfare  Center  Aircraft  Division  Indianapolis 
ATTN;  Mr.  Dennis  Mocherman 
6000  East  21st  Street 
Indianapolis,  IN  46219-2189 
(317)353-3544 


Overview 


1 .  DoD  5000^  (Part  6,  Section  N/Part  9,  Section  B) 

Part  6,  Section  N.  of  DoOl  5000.2  provides  policies  and  procedures  to  establish  a  basis 
necessary  to  make  effective  u:>e>  of  CALS  and  related  information  technologies  durir^ 
the  life  cycle  of  defense  systems  and  equipment  Part  9,  Section  B.  of  DoDI  5000.2 
provides  policies  and  procedures  to  establish  a  basis  for  an  effective  program  for 
management  of  technical  data  and  technical  manuals. 

2.  Acquisition  information  Strategy 

The  Acquisition  Information  Strategy  provides  information  on  CALS,  developed  in 
accordance  with  DoDI  5000.2,  that  is  to  be  included  in  acquisition  documents. 

3.  JCMO/DoD  Acquisition  Guide  for  impiementation  of  CALS 

The  purpose  of  this  acquisition  guide  is  to  assist  the  acquisition  mar^ger  and 
supporting  staff  in  implementing  CALS  during  the  acquisition  process  •*  from  acquisition 
strategy  to  contract  award.  Tnis  guide  will  assist  in  contracting  for  digital  data  products 
and  sen/ices  by  focusing  on  the  development  of  the  acquisition  strategy  and  solicitation 
documentation  with  sound  CALS  requirements. 

4.  Guide  for  Developing  a  CALS  GCO 

This  document  provides  guidance  to  acquisition  managers  and  others  who  have  an 
interest  in  applying  CALS  to  the  acquisition  of  data  products  in  support  of  weapons 
systems.  This  guidance  in  the  form  of  a  Government  Concept  of  Operation  (GCO), 
identifies  typical  user's  needs  for  technical  data  throughout  all  life  cycle  activities  of 
weapons  systems  management,  design,  manufacture,  and  support  functions. 

5.  Sample  Statement  of  Work  Language 

This  generic  Statement  of  Work  (SOW)  provides  sample  language  to  assist  in  the 
implementation  of  CALS  for  an  acquisition  program.  This  CALS-related  language 
should  be  used  in  developing  the  functional  requirements  within  each  applicable 
section  of  the  Request  for  Proposal  (RFP). 

6.  Applying  CALS  to  the  Creation,  Management,  and  Use  of  Technical  Data 
Packages 

This  document  is  intended  to  provide  the  acquisition  manager  with  an  overview  of 
Navy/Marine  Corps  business  practices  for  the  creation,  management,  and  use  of 
technical  data  packages  (TDPs)  in  a  CALS  environment.  The  document  also  provides 
information  on  various  digital  data  media,  format,  and  content  options  available  for 
obtaining  TDPs. 


7.  Applying  CALS  to  the  Creation,  Management,  and  Use  of  Technical 
Manuals 

This  document  is  intended  to  provide  the  acquisition  manager  with  an  overview  of 
Navy/Marine  Corps  business  practices  for  the  creation,  management,  and  use  of 
technical  manuals  (TMs)  in  a  CALS  environment.  The  documerrt  also  provides 
information  on  various  digital  data  media,  format,  and  content  options  available  for 
obtaining  TMs. 

8.  Applying  CALS  to  the  Logistic  Support  Analysis  Process 

This  document  is  intended  to  provide  the  acquisition  manager  with  an  overview  of 
Navy/Marine  Corps  Business  practices  for  the  creation,  management,  and  use  of  ILS 
and  LSAR  data  in  a  CALS  environment.  The  document  also  provides  information  on 
various  digital  data  media,  format,  and  content  options  available  for  obtaining  ILS  and 
LSAR  data. 

9.  CALS  Standards  Overview 

This  document  presents  a  brief  summary  of  the  initial  CALS  standards  including  their 
purpose,  current  status,  and  implementation  issues.  It  concentrates  on  the  CALS 
specifications  implemented  by  MIL-STD-1840,  Automated  interchange  of  Technical 
Information. 

1 0.  Program  CALS  Self  Assessment  Checklist 

This  checklist  provides  information  to  be  addressed  when  developing  and  updating 
acquisition/program  requirements  documents  in  a  CALS  environment  over  the  complete 
life  cycle  of  a  weapons  system  program.  Key  areas  include:  program  documentation; 
technical  manuals;  technical  data  (drawings);  logistics  support  analysis;  supply  support; 
and  manpower,  personnel,  and  training. 

1 1 .  Points-of-Contact  Listing 

This  section  provides  information  on  key  personnel  in  the  Navy/Marine  Corps  CALS 
program  that  can  provide  assistance/direction  in  the  development  and  implementation 
of  acquisition  guidance  in  the  CALS  environment. 

12.  Infrastructure  Requirements  For  The  Creation,  Management,  And  Use  '  * 
Digital  Data 

This  Section  provides  information  on  developing  and  updating  hardware,  software,  and 
network  program  requirements  in  a  CALS  environment. 
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FIGURE  INTRO-1 :  CALS  in  the  Acquisition  Process 


Navy/Marine  Corps 
Manager 's  Desktop  Guide 
FOR  CALS  Implementation 


Second  Edition 
30  June  1993 


GUIDE  CONTEMTS 


1 .  DoDI  5000^  (Part  6,  Saction  N/Part  9,  Section  B) 

2.  Acquisition  Information  Strategy 

3.  JCMO  DoD  Acquisition  Guide  For  hnpiementation  Of  CALS 

4.  Guide  For  Developing  A  CALS  GCO 

5.  SAMPLE  Statement  Of  Work  Language 

6.  Appiying  CALS  To  The  Creation,  Management,  And  Use  Of  Technical  Data  Packages 

7.  Applying  CALS  To  The  Creation,  Management,  And  Use  Of  Technicai  Manuais 

8.  Applying  CALS  To  The  Logistic  Support  Analysis  Process 

9.  CALS  Standards  Overview 


10.  Program  CALS  Self  Assessment  Checklist 

11.  Points-Of-Contact  Listing 

12.  Infrastructure  Requirements  For  The  Creation,  Management,  And  Use  Of  Digital  Data 


SECTION  1 

DoDI  5000.2 

(Part  6,  Section  N/Part  9,  Section  B) 


Parte 


Feb.  23, 1991 
5000Z  Pane 
Section  N 


Section  N 

COMPUTER-AIDED  ACQUtSmON  AND  LOGtSTICS  SUPPORT 


References: 

a.  Deputy  Seaetary  of  Defense  Memorandum.  'Computer-Aided  Acquisition  and  Logistics 
Support,'  August  5, 1988  (canceled) 

b.  MIL-STD-1840, '  Automated  Interchange  of  Technical  Information' 

c.  MIL-STD-15S6,  'Government-Industry  Data  Exchange  Program' 

d.  MIL-HDBK-S9,  'Computer-Aided  Acquisition  and  Logistics  Support  Program 
Implementation  Guide* 

1.  PURPOSE 

a.  This  section  supercedes  Deputy  Secretary  of  Defense  Memorandum  'Computer-Aided 
Acquisition  and  Logistics  Support*  (reference  (a)). 

b.  These  policies  and  procedures  establish  ttre  basis  for  making  greater  use  of  computer 
aided  information  technologies  that  enable  process  improvements  in  design, 
manufacturing,  and  life-cycle  support  of  defertse  systems  and  equipment 

2.  POUCIES 

in  general,  preference  shall  be  given  to  contractor  information  services  and  online  access 
instead  of  data  deliverables.  Where  data  delivery  is  required,  preference  shall  be  given  to 
delivery  in  machine-readable  digital  form  rather  than  paper  wherever  feasible. 

3.  PROCEDURES 

a.  Proposals.  Acquisition  plans  and  solicitations  will  require  specific  proposals,  including 
costs  and  schedule,  for 

1)  Integration  of  contractor  technical  {rrformation  systems  and  processes  for 
engineering,  manufacturing,  and  logistic  supped 

2}  Authorized  Government  access  to  contractor  data  bases;  and 

3)  Delivery  of  technical  information  in  digital  form  using  computer  aided  acquisition  and 
logistics  support  standards  contained  in  MIL-STD-1840  (reference  (b)). 

b.  Shared  Models  and  Data  Bases 

1)  Contractors  should  be  required  to  develop  integrated,  shared  data  base 
environments  consisting  of  analysis  tools,  consistent  integrated  databases,  and 
engineering  design,  manufactureing  aruf  logistics  processes  designed  to  utilize 
digital  information. 
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2.  Contractors  should  use  computer  aided  design,  enoineering,  and  manufacturing 
(CAD/CAE/CAM)  methods  to  suppon  design  integration  through  shared  product  and 
process  models  and  data  bases. 

c.  Management  Structure.  A  comprehensive  technical  information  management 
architecture  to  include  supporting  data  dictionary  arKf  directory  services  should  be 

developed  to: 

1)  Manage  configuration  of  the  entire  technical  information  and  plann^g  databases; 

2)  Integrate  planning  information  into  its  respective  technical  information  source 
database; 

3)  Provide  traceability  and  audibility  of  technical  information  relating  to  the  weapon 
system,  its  components,  artd  any  changes  affecting  them;  and 

4)  Trace  configuration  changes  from  design  to  logistics  products  arxf  vice-versa. 

5)  Exploit  opportunities  to  obtain  cost  savings  by  retrofitting  digital  information 
technology  into  deployed  weapon  systems. 

d.  iwformation  Services.  Contractor  integrated  technical  informafion  services  should  be 
developed  to  indude  procedures,  processes,  specifications,  and  software  applications  for 
the  generation,  protection,  integration,  storage,  exchange,  and  online  access  of  digital 
data  by  the  Government  and  associated  contractors. 

e.  Government-Industry  Data  Exchange  Program  fGIDEP).  The  Government-Industry 
Data  Exchange  Program  is  the  DoD  program  that  provides,  without  charge,  an 

unclassified  data  base  of  parts  problems,  reliability,  diminishing  manufacturing 
resources,  and  metrology  information. 

1)  The  Government-Industry  Data  Exchange  Program  is  described  in  MIL-STD-1556 
(reference  (c)). 

2)  The  Government-industry  Data  Exchange  Program  should  be  used  by  both  program 
offices  and  contractors. 

f.  Access  and  Delivery  Alternatives.  MIL-HDBK-59  (reference  (d))  provides 
technicalguidance  for  seleding  amcmg  information  access  and  deGvery  alternatives. 
Final  decisions  on  implementation  of  contractor  proposals  will  be  based  on  the 
productivity  and  quality  improvements  expected  in  contractor  team  operations  (prime, 
subcontractors,  suppliers)  and  Government  operations. 
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1)  Technical  data  that  are  required  as  deliverabtes,  including  technicalmanuats, 
engineering  data,  and  logistics  support  analysis  data,  should  be  required  to  be 
prepared  and  delivered  in  digital  form  unless  dear  and  convindng  analysis  shows 
this  not  to  be  cost-effective  when  assessed  across  the  life  cycle. 

2)  The  computer  aided  acquisition  and  logistics  support  starulards  in  MIL-STD-1B40 
(reference  (b))  will  be  applied  for  digital  data  deliverables. 

4.  RESPONSIBILITIES  AND  POINTS  OF  CONTTACT 

The  matrix  below  identifies  the  offices  to  be  contaded  for  additional  information  on  this  section. 

The  full  titles  of  these  offices  may  be  fourvl  in  Part  14  of  this  Instruction. 


DoO  Component 

Points  of  Contact 

General 

Specific 

OSD 

ASD  fP&U 

DASD  fPR)/CALS 

Dept,  of  Army 

ASA(IL&Q 

SAILE-LOG 

Dept  of  Navy 

ASN  (RDA) 

DCNO  (OP-04) 
HQMC/I&L 

Dept  of  Air  Force 

SAF  (AQK 

AF/LE-I 
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PARTS 
SECTION  B 

TECHNICAL  DATA  MANAGEMENT 


References; 

a.  DoO  Instruction  5010.12,  'OoO  Technical  Data  Management  Program.'  January  23, 
1989  (canceled) 

b.  OoO  Instruction  4151.9,  'DoO  Technical  Manual  Program  Management,*  January  3, 
1989  (canceled) 

c.  DoO  5010.12-L  'Acquisition  Management  Systems  and  Data  Requirements  Control  List 
(AMSOL),*  reissued  Semi-Annually  in  April  and  October,  authorized  by  this  Instruction 

d.  OoO  5025.1 -M,  'Department  of  Defense  O^ectives  System  Procedures,'  December 
1990,  Authorized  by  DoD  Directive  5025.1,  'Department  of  Defense  Directives  System,' 
December  23, 1988 

e.  TitlelO,  United  States  Code,  Section  2302, 'Definitions' 

f.  MIL-STD-1840,  'automated  interchange  of  Technical  Information' 

g.  MIL-HOBK-59,  'Computer-Aided  Acquisition  and  Logistics  Support  Program 
Implementation  Guide' 

h.  Public  Law  96-511, 'Paperwork  Reduction  Act  of  1980* 

i.  Federal  Acquisition  Regulation  (FAR),  Part  27,  'Patents,  Data,  and  Copyrights* 

j.  Defense  Federal  Acquisition  Regulation  Supplement  pFARS),  Part  227,  'Patents,  Data, 
and  Copyright* 

k.  MIL-STD-1 806,  'Marking  Technical  Data  Prepared  by  or  for  The  Department  of  Defense* 

l.  DoD  Directive  5200.21,  'Dissemination  of  DoD  Technical  Information,'  September  27, 
1979 

m.  DoD-STD-963,  'Data  Item  Descriptions  pIDs),  Preparation  of 

n.  DoD-STD-1700,  'Data  Management  Program' 

o.  Technical  Data  Package,  Gerteral  Spedficalions  for* 

1.  PURPOSE 

a.  This  section  replaces  DoD  Instruction  5010.12,  *  DoD  Technical  DataManagen>ent 
Program*:  and  DoD  instruction  4151.9,  *  DoD  Technical  Manual  Program  Management* 
(references  (a)  and  (b)),  which  have  bem  canceled. 

b.  These  poficies  and  procedures  establish  the  basis  for  an  effective  program  for 
management  of  technical  data  and  technical  manuals.  These  policies  and  procedures 
do  not  apply  to; 

1)  Technical  data  for  cryptologic  activities. 
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2)  Technical  manuals  for  nuclear  weapon  systems  supported  by  publications  under  the 
Joint  Nuclear  Weapons  Publications  System,  or 

3)  Data  submitted  by  an  offerer  in  resportse  to  a  request  for  proposal  (RFP) . 

c.  This  section  authorizes  the  Assistant  Secretary  of  Defense  (Production  and  Logistics)  to 
publish  DoD  5010.12-L,  'Acquisition  Management  Systems  arKi  Data  Requirements 
Control  List  (AMSDL)'  (reference  (c))  and  DoD  5010.12-M,  ‘Procedures  for  the 
Acquisition  and  Management  of  Technical  Data*  in  accordance  with  DoO  5025.1 -M, 
'Department  of  Defense  Directives  System  Procedures*  (refererKe  (d)). 

2.  POLICIES 

a.  Technical  data,  is  defined  in  Titie  10.  United  States  Code,  Section  2302,  'Definitions 
(reference  (e))  as  recorded  information  (regardless  of  the  form  or  ntethod  of  the 
recording)  of  a  scientific  or  technic^  nature  fibduding  computer  software 
documentation)  relating  to  supplies  procured  by  an  agency.  Technical  data  does  not 
include  computer  software  or  financial,  administrative,  cost  or  pridr^,  or  manageirrent 
data  or  other  information  incidental  to  contract  administration. 

1)  Technical  data  is  required  to  define  and  document  an  engineering  design  or  product 
configuration  (sufficient  to  allow  du;riication  ot  the  original  items)  arxl  is  used  to 

-  support  production,  ertgineering.  and  logistics  activities. 

2)  A  technical  data  package  shall  irxAide  ail  engineering  drawings,  associated  lists, 
process  descriptions,  and  other  documents  which  define  the  physical  geometry, 
material  composition,  performance  characteristics,  manufacture,  assembly,  and 
acceptance  test  procedures. 

3)  Technical  data  which  provides  instructions  for  the  installation,  operation, 
maintenance,  training,  and  support  of  a  system  or  equipment  can  be  fornatted  into  a 
technical  manual. 

sO  A  technical  manual  normally  includes  operation  and  maintenance  instructiorts, 
parts  lists  or  parts  breakdown,  arxf  related  technical  information  or  procedures 
exclusive  of  administrative  procedures. 

b)  This  data  may  be  presented  in  any  form  (e.g.  hard  copy,  audio  and  visu^^l 
displays,  magnetic  Uqie,  disks,  or  other  electronic  devices). 

c)  Technical  orders  that  meet  the  criteria  of  this  definition  may  also  be  classified  as 
technical  manuals. 

b.  The  DoD  Ck>mponent  having  management  responsibility  for  an  Item  shall  ensure  that  the 


9-B-2 


Feb  23.  91 
5000.2,  PART  9 
SECTION  B 


Government  has  complete  access  to  the  data  necessary  to  support  the  essential 
requirements  of  all  users  throughout  the  Item's  life  cycle.  This  access  may  be  achieved 
by: 

1)  Procuring,  storing,  and  maintairung  tiie  necessary  data  in  a  Government  data 
repository:  or 

2)  Procuring  access  to  the  data  through  a  contractor  integrated  techrticai  information 
service  (see  Section  6-M). 

3.  PROCEDURES 

a.  Establishino  Data  Reouirements 

1)  User  data  requirements  will  be  established  by  use  of  a  data  call  to  ail  potential  users. 

a)  A  data  requirements  review  board  will  be  established  to  review  data  call 
recommendations  aruf  advise  the  Program  Manager. 

b)  A  data  requirements  review  board  will  be  convened  before  issuing  a  solicitation 
for  arty  acquisition  having  a  potential  cost  of  $5  million  or  more. 

2)  Only  the  minimum  data  needed  to  permit  cost>effective  support  ofresearch, 
-  development,  production,  cataloging,  prc^sioning,  training,  operation,  maintenance, 

and  related  logistics  functions  over  the  Rfe  cyde  of  the  item  will  be  acquired. 

a)  When  the  production  contract  for  a  single  design  is  to  be  competed,  product 
drawings  and  associated  iiste  must  be  delivered  by  the  end  of  Phase  II, 
Engineering  and  Manufacturing  DevelopmenL 

b)  Production  contracts  must  include  product  drawings  and  associated  lists  for 
items  that  will  be  reprocured  or  manufactured  in-house.  When  appropriate,  the 
data  package  will  include  information  suitable  to  compete  repimishment  of 
subtler  spare  parts  including  part  level  acceptance  test  procedures. 

3)  Standard  data  Item  descriptions  (DIDs)  that  exceed  the  requirements  of  the  data 
needed  must  be  tailored.  Tailoring  maybe  accomplished  to: 

a)  Accept  contractor  format,  or 

b)  Reduce  the  scope  through  de'3tion  or  selection  of  existing  words,  paragraphs,  or 
sections. 

4)  Contract  provisions  must  ensure  that  contractors  and  subcontractors  prepare  and 
update  technical  data  packages  as  an  integral  part  of  their  design,  development,  and 
production  effort  and  must  define  the  contractor^  responsibility  for  accuracy  and 
completeness  of  technical  data  packages  and  technical  manuals.  All  technical  data 
and  technical  manuals  will  be  updated  to  reflect  approved  design  changes  and  made 
available  concurrent  with  the  implementation  of  the  change. 
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5)  Data  should  be  ordered  in  contractor  format  unless  the  Government  format  is 
necessary  or  more  cost*effective.  Maximum  use  wfll  be  made  of  commercial 
technical  manuals,  or  their  modifications,  that  meet  DoO  Component  requirements. 

a)  Contract  deliverable  data  win  be  prepared  and  used  in  digital  form  unless  it  is  not 
cost-effective  for  the  Government  Maximum  use  should  be  made  of  available 
contractor  automated  data  bases.  Data  to  be  delivered  in  digital  form  will 
comply  with  computer  aided  acquisition  and  logistics  support  (CALS)  initiatives 
and  MIL-STD-1840  (refererx^  (f)).  Refer  to  MIL-HDBK-59  (reference  (g))  for 
guidance  in  selecting  the  specific  digital  data. 

b)  When  options  are  estabfished  for  defivery  of  digital  data,  the  program  office  will 
ensure  that  all  the  recipient  of  the  digital  data  have  the  necessary  capability  to 
receive,  store,  and  maintain  the  data.  Where  operational  units  are  recipients, 
the  system  design  should  include  the  necessary  capability  to  receive,  store,  and 
dispi^  the  data. 

c)  Technical  manuals  must  be  written  to  the  reading  and  skill  levels  of  the  people 
for  whom  they  are  intended  to  ensure  that  the  target  audience  urrderstands  the 
technical  manual  text  or  text-graphics  combination. 

6)  Logistics  support  analysis  data  wOl  be  used  to  the  maximum  extent  to  define  and 
develop  source  data  for  technical  manuals. 

b.  Plannino  for  New  Technical  Manuqis.  Plans  will  be  developed  for  each  new  group  of 
technical  manuals  supporting  a  weapon  system,  weapon  system  component,  or  support 
equipment  to  ensure  the  technical  accuracy  and  adequacy  of  technical  rrranual  content. 
These  plans  will  provide  for. 

1)  The  optimum  number  and  types  of  conventional  publications  and  other  media  such 
as  audiovisual  systems,  tape,  disc,  or  other  electronic  devices; 

2)  Technical  manual  availability  in: 

a)  Preliminary  form  using  contractor  in-house  manuals  and  repair  and  test 
documentation,  as  practicable,  until  the  design  is  stable,  and 

b)  Final  form  for  the  programmed  operational  date  for  the  equipment  or  system, 
except  for  materiel  under  contractor  support 
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3)  Clear  definition  of  contractor's  responsibility  for  accuracy  and  completeness  of 
technical  manuals  and  contractor  and  DoO  Component's  participation  in  validation 
and  verification;  and 

4)  Review  of  technical  manual  plans  durmg  irvprocess  reviews  to  ensure  timely 
completion  of  validation  and  verification  in  time  to  support  realistic  operationai  test 
and  evaluation. 

c.  Data  Acquisition  Documents.  Specific  requirements  for  the  preparation  of  deliverabie 
data  or  for  record  keeping  are  to  be  documented  in  specifications,  standards,  and  data 
hern  descriptions,  coUectiveiy  known  as  data  acquisition  documents. 

1)  Data  requffements  in  solicitations  and  contracts  will  be  selected  from  data  Item 
descriptions  listed  in  the  Acquisition  Management  Systems  and  Data  Requirements 
Control  List  (reference  (c)).  Before  being  listed  in  the  Acquisition  Management 
Systems  and  Data  Requirements  Control  List,  new  or  revised  data  item  descriptions 
wnt  be  reviewed  by  the  Acquisition  Management  Systems  and  Data  Requirements 
Control  List  clearance  office  in  compliance  with  the  requirements  of  Public  Law  96- 
511,  ‘Paperwork  Reduction  Act  of  1980*  (reference  (h)). 

2)  A  one-time  data  Item  description  may  be  developed  to  define  the  content  and  format 
requirements  of  a  data  product  if  an  appropriate  data  Kern  description  is  not 
contained  in  the  Acquisition  Management  Systems  and  Data  Requirements  Control 

.  List.  One-time  data  item  descriptions  win  be  used  on  only  one  contract 

3)  One-time  data  Item  descriptions  will  be  approved  in  accordance  with  DoO 
Component  procedures.  A  recced  of  such  approvals  will  be  maintained  within  each 
DoO  Component.  An  annual  listing  of  approvals  as  of  September  30  will  be 
submitted  to  the  Acquisition  Marragement  Systems  and  Data  Requirements  Control 
List  clearance  office  no  later  than  November  30  of  each  year. 

4)  Data  item  descriptrans  adll  not  be  used  to  delineate  requirements  for  technical 
manuals  for  weapon  systems,  weapon  systems  components,  or  support  equipment 
These  manuals  will  be  acquired  by  line  item  and  have  an  exhibit  attached  to  the 
acquisition  document  The  acquisftion  of  technical  manual  administrative  and/or 
management  data  such  as  status  reports,  validation  plan  schedules,  and  manuals 
other  than  those  to  support  a  weapon  system  shaB  be  acquired  by  Data 
ItemOescription. 

d.  OrderrnQ.  Dertverv.  Inspection,  and  Acceptance  of  Data  Data  will  be  ordered,  delivered, 
inspected,  and  accepted  in  accordance  with  the  Federal  Acquisition  Regulation  and 
Defense  Federal  Acquisition  Regulation  Supplement  (references  (Q  and  0). 
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e.  Righm  in  nnni  Acquisition  of  rights  in  technicai  data  will  be  in  accordance  with  the 
Federal  Acquisition  Regulation  and  Defense  Federal  Acquisition  Regulation  Supplement 
(references  (Q  and  0). 

f .  Wan-wnh/  of  Data.  Acquisition  of  data  warrarties  wil  be  in  accordance  with  the  Defense 
Federal  Acquisttion  Regulation  Supplement  (reference  0). 

g.  Distribution  Statements  7"  Data,  Technical  data  will  be  marked  in  accordance 

with  the  Defense  Federal  Acquisition  Regulation  Supplement  (reference  0)  arKf  MIL- 
STD-1806  (reference  (ig)  to  denote  the  extent  to  which  the  data  may  be  distrbuted 
without  further  approval  of  the  controIBng  DoD  office. 

h.  Data  Repositories.  Technicai  data  packages,  software  media,  and  associated  data  will 
be  received,  inventoried,  inspected,  accepted,  indexed,  stored,  and  managed  to  provide 
maximum  accessibility  to  DoD  Components  and  to  ensure  that  contractor  data  rights  are 
protected. 

1)  DoD  Component  Heads  will  establish  and  maintain  index  entries  for  Milttary 
Engineering  Data  Assets  Locator  System  (MEDALS).  Data  elements  for  those 
indices  w9  be  coordinated  with  other  DoD  Components  to  maximize  the  interchange 
of  data  assets. 

2)  An  irt-house  technical  manual  inventory  and  index  system  will  be  estabfished  in  each 
.  DoD  Component  to  improve  the  management  and  exchange  of  technical  manuals. 

3)  Arrangements  may  be  made  for  the  contractor  to  serve  as  a  temporary  repository  for 
data  in  the  development  and  production  phases  of  a  program.  When  the  contractor 
serves  as  the  data  repository,  the  Government's  rights  to  access  and  subsequent 
delivery  through  a  deferred  dePvery  plan  wiU  be  protected. 

i.  Release  of  Data.  To  the  maximum  extent  allowabie  by  law  and  regulation,  DoD 
Components  wiU  provide  or  make  available  requested  data  in  accordarKe  with  applicable 
portions  of  the  Federal  Acquisition  Regulation  and  Defense  Federal  Acquisition 
Regulation  Supplement  references  (9  and  0. 

j.  Additional  Guidance.  Additional  guidance  is  contained  in  DoD  Directive  5200.21,  MIL- 
STD-963,  DoO-STD-1700.  and  MIL-T-3100  (references  (1)  through  (o)). 

4.  RESPONSIBILITIES  AND  POINTS  OF  COf^n-ACT 

The  matrix  on  the  next  page  identifies  the  offices  to  be  contacted  for  additional  information  on 
this  section.  The  full  titles  of  these  offices  may  be  found  in  Part  14  of  this  Instruction. 
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Points  of  Contact  | 

General 

Specific 

OSD 

ASD/P&U 

DASD(PR)/SOM 

Dept  of  Army 

ASA(ROA) 

SARD-ZP 

Dept  of  Navy 

ASN(ROA) 

Dep,  APIA 

Dept  of  Air  Force 

AFA£ 

AF/LEY 

Other  DoD 

Components 

DLA 

DLA-SE 
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ACQUISITION  INFORMATION  STRATEGY 


The  following  information  on  Comptitar*«lded  Acquisition  and  Logistic  Support  (CALS)  is  to 
be  included  in  acquisttion  documents.  These  inputs  are  based  upon  the  requirements  of  DoOl 
5000.2,  Part  6,  Se^n  N  and  are  consistent  with  DoN  strategy  for  CALS  implemeidation. 


The  Integrated  Program  Summary  (ApperKfbc  C  of  the  Acquisition  Strategy  R^xvQ,  should 
include  the  following  statement: 

The  PCXX]  program  will  take  advantage  of  existing  and  emerging  automation  and 
integration  capabilities  to  establish  a  eomputsr*based  environment  for  creating, 
managing  and  storing  data  elements  once  for  multiple  applications  across  engineering, 
design,  manufscturing  and  iogistles  functions  and  processes. 


The  Acquisition  Plan  (AP)  should  also  indude  the  following  statement,  applicable  for  the 
competitive  System  OeriWal,  E&MO  and  LRIP  efforts: 

The  POOC]  project  Intends  to  Implement  CALS  Initiatives  to  reduce  Ilfs  cycle  costs. 
Improve  product  quality,  reduce  program  risk  and  reduce  the  schedule  of  the  design, 
development  and  production.  The  technical  Information  required  in  support  of  the 
project  will  be  made  accessible  through  oivllne  contractor  integrated  technical 
information  (electronic)  services;  physical  delivery  of  data  required  for  sustaining 
support  activities  will  be  In  accordance  with  approved  CALS  format  standards  and 
sp^fications.  For  contract  data  requirements  not  evaluated  as  cost-effectively  dellveied 
to  the  6als  standardWapecifIcatlons,  delivery  will  be  in  mutuaOy  agreeable  digital 
formats.  The  digital  formats  for  all  data  users  and  user  systems  will  be  determirwd 
cooperatively  between  the  govemmertt  and  contractor  using  ^  Government  Concept  of 
Operations  (GCO),  developed  by  the  government  program  office,  as  the  basis  for 
selection. 

The  draft  and  flrwl  RFPs  will  incorporate  requirements  for  the  offeror  to  address 
Implementation  of  concurrent  engineering  and  digital  deilvery/eiectronie  access  of 
program  technical  information.  Significant  weighting  will  be  applied  to  the  CALS  element 
In  source  selection  evaluation  (not  less  than  10  percent  of  the  total  evaluation/rating). 
Oftarora  will  be  evaluated  on  their  ability  to  provide  Integrated,  shared  data  bases 
environments  for  engineering  arwiysis,  design,  manufacturing  and  logistic  processes; 
and  their  use  of  CAO/CAM/CAE  methods,  product  models/data  bases  and  simulation 
tools  to  Improve  product  design,  testing,  manu:  acturing  and  support  system 
development  The  program  will  Integrate  speciflc  program  solutions  with  *''*>36 
developed  by  DoO/DoN  infrastructure  modernization  initiatives  and  will  implement  where 
value-effective,  joint  service  CALS  systems  for  the  creation,  marwgement  and  use  of 
digital  technical  information.'' 
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NOTE 


The  following  section  has  been  retained  within  the  Second  Edition  of 
the  Navy/Marine  Corps  Manager's  Desktop  Guide  for  CALS 
Implementation  for  historical  and  general  informational  purposes  only. 
Those  areas  where  this  section  is  in  conflict  with  other  portions  of  the 
Desktop  Guide  or  other  more  current  CALS  documentation  should  bej 
disregarded.  _ 


DEPARTMENT  OF  THE  NAVY 

JOINT  CALS  MANAGEMENT  OFFICE  (JCMO) 

SKVUNE  SIX,  ROOM  310 
5109  LEESBURG  PIKE 
FALLS  CHURCH,  VA  22041 

MemoJCMQ/OOOIS 
April  16, 1991 


MEMORANDUM  FOR  THE  DISTRIBUTION  UST 

Sut^:  Computer-Aided  Acquisition  and  Logistics  Support  (CALS)  Acquisition  Guidance 

End:  (1)  Departmart  of  Defense  Acquisifion  Guide  for  Impiementadon  of  Computer-aided 
Acquisition  and  Logistics  Support  (CALS) 


1.  Despite  the  formal  promulgation  of  the  OoD  initiative  to  trar»f6rm  the  acquisition  and  Bfe 
cycle  support  processes  from  a  paper-intensivB  to  a  highly  automated  environment  through 
CALS,  a  lack  of  specific  targeted  information  is  ir^tibitmg  the  ability  of  the  individual  weapons 
systems  program  managers  to  implamont  CALS  in  a  unifonn,  effective  manner.  As  a  resuft,  the 
degree  to  which  CALS  has  been  irnplemented  within  individual  acquisition  has  been  variable. 

2.  Enclosure  (1)  is  the  product  of  a  joint  service  initiative  to  respond  to  this  defidoncy.  The 
Acquisition  Guide  contains  an  accumulation  of  information  and  guidance  to  improve 
implementation  of  CALS  in  weapon  system  acquisition  programs.  The  information  and  guidance 
containerfin  endosurs  (1)  has  been  coordinated  with  the  CALS  Industry  Steering  Group  (ISG) 
and  is  consistent  with  detailed  technical  methodologies  included  in  MIL-HDBK-59A.  The 
information  was  assembled  from  program  managers  who  have  successfully  in^mented  and 
benefitted  from  CALS  and  from  irKfividuai  Service  CALS  cuivocates  acting  in  a  ma^  support  role 
to  individual  acquisition  programs. 

3.  The  guide  provides  information  useful  to  personnel  resportsible  for  the  acquisition  arxi 
use  of  weapon  system  technical  data  Its  purpose  is  to  assist  Kquisition  managers 
transitioning  from  paper-intensivB  processes  to  dgi^  data  delivery  and  access.  It  also  supports 
the  structuring  of  contact  requirements  to  achieve  integration  of  varfous  contractor  automated 
capabilities  for  design,  manufocturing,  and  logisbcs  support 

4.  Throughout  this  guide,  reference  is  made  to  the  CALS  handbook.  MIL-HDBK-59A.  This 
handbook  is  available  from  the  National  InstitiAe  of  Standards  and  Techriology,  telephone  (301) 
975-6641/2  or  the  Navy  Publications  and  Forms  Center. 

5.  Addressees  are  encouraged  to  distribute  and  utilize  enclosure  (1)  for  use  in  developing 
CALS  requirements  within  individual  acquisitions.  In  order  to  maintain  consistency  and  uniformity 
of  the  A^uisition  Guide,  the  Joint  CALS  Management  Office  (JCMO)  will  coordinate  any 
proposed  revisions  to  this  document  with  the  services  and  DLA.  Beneficial  comments 


This  memo  has  been  recreated  and  reprinted  for  the  purposes  of  this  Manager's  Guide  to  the 
Application  of  CALS. 


(recommendations,  additkms,  deletions)  and  any  pertinent  data  that  may  be  of  use  m  improving 
this  document  should  be  addressed  to: 


Joint  CALS  Management  Office 
Skyline  Six,  Suite  310 
5109  Leesburg  Pike 
Falls  Church,  Va  22041 

6.  The  following  irnfividuais  may  be  contacted  for  additional  information  or  clarification: 

JCMO  •  Mr.  Matt  Weden  (703)  756-0996 
NAVY  •  Mr.  Shawn  McGil  (703)  746-0840 
ARMY  -  Mr.  Mark  Mohe  (205)  842-2673 
A.F.  -  Mr.  Dennis  Rogash  (513)  255-7371 
USMC  -  Capt  Jeff  Everest  (703)  696-1180 


W.L  Hides 
Director, 
Joint  CALS 

ManagemeiS 

Office 


Distribution: 

OSD  CALS  Storing  Board 

JTCG-CALS 

FOSC 

DONCSB 

DA(AMC) 

USAF(LG) 

DLA(2) 

CMC  (L)  (MCRADC) 
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This  acquisition  guide  was  developed  by  the  Department  of  Defense  with  the  assistance  of  the 
military  departments,  defense  agencies  and  industry. 
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1.0  Introduction 


Computer-aided  Acquisition  and  Logistic  Support  (CALS)  is  a  strategy  that  enables  more 
effective  generation,  exchange,  use  and  management  of  defense  systems  and  equipment 
technical  information.  These  types  of  technical  information  include  management, 
design/engineering,  manufacturing,  logistic  support  and  operations  infonnation. 

Within  the  emerging  CALS  environmerrt,  process  improvements,  such  as  Concurrent 
Engineering,  are  being  applied  to  improve  acquisition  efficiency  and  product  quality.  CALS  is  an 
integral  part  of  the  acquisition  process  and  is  consistent  with  Acquisition  Streamlining  and  Total 
Quality  Management  (TQM)  efforts.  The  CALS  target  is  an  integrated  information  environment 
that  will  enable  continuous  process  improvement 


1.1  Purpose/Scooe 

The  purpose  of  this  acquisition  guide  is  to  assist  the  DoD  Acqusition  Manager  and  supporting 
staff  in  implementing  CALS  during  the  acquisition  process-from  acquisition  strategy  to  contract 
award.  The  material  contairted  herein  is  advisory,  not  mandatory.  Specific  details,  inciuding 
technical  arui  acquisition  guidance,  are  available  in  MIL-HOBK-59A. 

This  guide  wiO  assist  in  contracting  for  digital  data  products  and  senrices  by  focussing  on  the 
development  of  an  acquisition  strategy  and  solicitation  documentation  with  sound  CALS 
requirements.  Information  is  provided  for  developing  requiremeiSs  in  the  foliowing  areas: 

a)  Automation  and  integration  of  contractor  technical  inibnnation  systems  and  functional 
processes; 

b)  Authorized  government  access  to  contractor  data  bases;  and, 

c)  Delivery  of  weapon  system  technical  data  in  digital  form. 

It  is  important  to  remember  while  reading  this  guide  that  'CALS  deliverabies'  and  'CALS 
requirements'  are  not  entities  in  themselves,  but  refer  to  m^hods  arrd  standards  for  receivirrg 
program  data,  traditionaily  delivered  on  paper,  in  digital  forra 


2.0  Acquisition  Strategy  and  CALS 

The  Acquisition  Manager,  in  developing  an  acquisition  stratr^gy,  must  consider  CALS 
impieinentation  arxl  its  potential  for  improving  acquisition  and  logist.cs  support  processes.  The 
approach  to  CALS  implementation  will  vary  by  program  acquisition  phase  and  by  program  type, 
size  and  duration.  This  guide  is  focussed  piiman1y  on  CALS  implementation  for  the  acquisition  of 
major  defense  systems  and  equipment;  however,  the  information  provided  will  prove  useful  for 
other  acquisitions,  including  less  than  major  systems  (ACAT  lll/IV),  spares  reprocurement, 
product  improvements,  and  Non-Developmental  Items/Commercial  Off-the-Shelf  (NDI/COTS). 
The  Acquisition  Manager  must  assess  particular  program  requirements  to  arrive  at  the  most 
effective  CALS  implementation  strategy. 
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The  information  requirements  of  each  program  are  unique  and  the  opportunities  for  cost-effective 
application  vary  among  contractors.  To  maximize  the  potential  benefits  to  be  gained  from  CALS, 
the  Acquisition  Manager  must  develop  a  CALS  implementation  strategy  as  an  integral  part  of  the 
program  acquisition  strategy.  A  compete  CALS  implementation  strategy  includes  three  primary 
elements: 

a)  Government  Cor''<;pt  of  Operations  (GCO).  The  Government  concept  of  digital  data 
usage  through  each  phase  of  the  life  cy^,  including  a  summary  of  Government  systems 
for  managing  the  data.  The  GCO  should  be  included  in  the  RFP. 

b)  CALS  RFP  Requirements.  Specific  data  integration,  data  access  and  digital  delivery 
requirements  to  support  the  GCO. 

c)  The  Role  of  CALS  in  Source  Selection.  The  structure  of  CALS  evaluation  criteria  and 
their  relative  importance. 

These  three  elements  are  essential  to  achieve  effective  snplementation  of  CALS  arxj  are 
discussed  in  more  detail  in  the  foiknving  sections  of  this  guide. 


3.0  Contracting  for  CALS 

3.1  Government  Concent  of  Operations  fGC^ 

The  objective  of  the  GCO  is  to  provide  potential  bidders  an  understanding  of  general  user  needs 
for  technical  data  and  user  ca^ilities  for  handling  digital  data  throughout  life-cycle  activities. 
Due  to  the.  varying  types  and  levels  of  data  required  during  the  life-cycle  phases,  it  is  likely  that 
the  GCO  will  vary  by  phase. 

Specific  data  formats  and  delivery  or  access  requirements  will  be  specified  in  the  contract  To 
provide  an  overall  framework  for  these  requirements,  the  GCO  must  address  the  following  factors 
for  each  type  of  contract  data  (i.e..  Program  Management  data.  Engineering  data.  Logistics 
Support  d£^  and  other  technical  plans  and  reports): 

1 .  The  specific  delivery  media  desired  (hard  copy,  on-iine  access  or  digital  delivery)  expected  for 
each  data  type. 

2.  For  categories  where  on-line  access  or  delivery  is  expected: 

a)  The  hardware  and  software  systems  the  Government  has  or  is  developing  to  manage 
and  use  the  data  (the  infrastructure). 

b)  The  data  users  and  user  locations. 

c)  How  the  data  will  be  used  (i.e.,  view  only,  modify,  comment,  manipulate,  etc...)  and 
the  review  and/or  approval  processes  to  support  program  functions  and  activities  (e.g., 
SDR,  PDR,  CDR,  PCA,  LSAR  reviews,  etc.). 

d)  How  the  Government  will  accomplish  inspection  and  acceptance  of  digitized 
iriformation  submitted  by  the  contractor. 
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e)  How  the  data  is  to  be  interchanged  using  applicable  starwiards  and  existing 
teiecommunication  capabilities  (see  MIL-HOBK-59A  for  detailed  description  of  the  use  of 
spedfications^tandards  and  communication  protocols). 

f)  Data  protection/security  requirements  including  access  authorizations  and  restrictions 
(classified,  sensitive,  and  proprietary  data,  etc...). 

The  Acquisition  Manager  should  work  with  appropriate  Service/Agency  CALS  focal  points  (see 
Appendix  A)  to  identify  government  capabilities  for  receiving,  accessing  and  cont^ng  data 
products  delivered  by  the  contractor. 

The  GCO  should  be  prepared  early  in  program  development  concurrent  with  the  preparation  of 
the  program  acquisMim  strategy  arxi  acquisition  plan.  The  Government  must  dearly  articulate 
the  GCO  in  the  weapon  system  Request  For  Proposal  (RFP).  This  wilt  ^ow  each  offeror  to 
address  the  data/infbrmation  needs,  in  a  cost  effective  manner,  within  their  irrdividual  CALS 
Implementation  Plan  (CALSIP)  as  discussed  in  paragraph  3.2.1 . 


3.2  CALS  RFP  Requirements 


The  diagram  in  Figure  1  depicts  the  contracting  methodology  for  addressing  CALS  in  a  program 
acquisition.  During  RFP  deveiopmenL  the  Acquisition  Manager  should,  as  a  minimum,  indude 
CALS  requirements  for  each  sedion  of  the  soridtation  as  follows: 

a)  -  Section  B.  Supplies  of  Services  and  Prices/Costs.  A  separate  Contract  Line  Item 
Number  (CUN)  shodd  be  induded  for  CITIS  services.  The  pridng  provided  for  this  line 
item  should  not  indude  the  cost  of  developing  the  data;  this  is  a  separate  requirement 
and  should  be  priced  separately.  The  cost  of  CITIS  is  defined  by  the  level(s)  of  service 
for  the  length  of  time  proposed  by  the  contrador  or  specified  in  the  Statement  of  Work. 
MIL-F-CITIS  PRAFT),  section  80,  provides  pricing  guidance. 


b)  Section  C.  DescripBon/Spedfication/Work  Statement  CALS  requirements  shaD  be 
specified  that  require  an  program  techrrical  information  to  be  created,  managed  arxl  used 
in  a  digital  data  base  environment  The  Acquisition  Manager  should  provide  reference  to 
the  attachment  that  contains  the  information  strategy/GCO.  The  Acquisition  Manager 
has  the  option  to  specify  delivery  of  a  detailed  CALS  Implementation  Plan  (CALSIP)  as  a 
separate  deliverable  (reference  the  Section  J  CDRL)  or  as  a  section  of  anoth«’  program, 
logistics  or  data  management  plan  (reference  the  Section  C  paragraph  requiring  the 
other  Plan).  When  CITIS  is  a  firm  RFP  requirement,  sedion  C  must  detail  the  specific 
ems  capabilities  required  by  tiie  Acquisition  Manager.  [Sample  SOW  language  to 
satisfy  general  CALS  requirements  can  be  found  throughout  MIL-HDBK  59A;  MIL-F- 
CITIS  praft)  provides  SOW  language  and  tailoring  guidance  for  CITIS  requirements]. 


c)  Sedion  E.  Insoedion  and  Acceptance.  Generally,  current  practices  apply;  however, 
the  Acquisition  Manager  should  consult  the  Service  CALS  point  of  contad  for  current 
guidance  when  preparing  this  sedion  of  the  RFP. 
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d)  Section  F,  Peclod  of  Perfomiance.  Generally,  current  practices  apply;  hovvever.  the 
Acquisition  Martager  should  consult  the  Service  CALS  point  of  contact  for  current 
guidance  when  preparing  this  section  of  the  RFP. 
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e)  Section  H.  Special  Contract  Requirements.  To  capitalize  on  opportunities  afforded  by 
information  technology  evolution,  a  Technology  or  Performance  Refreshment  clause 
should  be  considered.  The  Service  CALS  point  of  contact  should  have  an  example  of 
this  clause.  In  addition,  provisions  for  warranty  of  CITIS  performance,  addressed  in  MIL- 
F-Cms  (DRAFT),  and  contractual  incentive  mechanisms,  discussed  in  Appendix  A  of 
MIL-HDBK-59A.  section  40.3.4.4-5,  should  be  considered. 

f)  Section  J.  Attachments.  CDRLs  for  delivery  of  digital  data  arxf  Data  Item  Descriptions 
(DIDs)  identifying  digital  data  requirements  are  discussed  in  MIL-HDBK  59A,  Appendix  B, 
section  40.4.3;  Appendix  D,  section  50.2  provides  specific  i^jidanoe  on  section  of 
physical  mediate  dte  in  Block  16  of  the  CDRL 

g)  Section  L.  Instructions  to  Offerors  flTOI.  CITIS,  whether  a  firm  RFP  requirement  or 
an  evaluated  option,  should  be  described  in  a  CITIS  section  of  the  CALSIP  (see 
paragraph  3.2.1).  The  Acquisition  Manager  should  require  offerors  to  describe  the 
general  procedures,  specifications,  software  applications,  and  database  services  used  for 
the  generation,  storage,  and  digital  exchange  of  contract-specific  technical  information 
between  the  prime  contractor,  subcontractors,  and  the  Government  Acquisition 
Managers  should  require  offerors  to  address  specific  improvements  that  should  be 
attained  through  application  of  CITiS.  Sample  ITO  larrguage  to  propose  specific  CALS 
requirements  should  be  obtained  from  the  Service  CALS  point  of  contact. 

h)  Section  M.  Evaluation  Factors.  The  Acquisition  Manager  should  identify  the 
qualitative  and  quantitative  factors  that  will  serve  as  the  basis  for  evaluation  of  CALS 
(see  Section  3.3).  The  evaluation  factors  should  be  consistent  with  those  estabfished  in 
the  Source  Selection  Plan  to  ensure  that  numerical  and  narrative  starxlards  and  weights 
can  be  applied  during  the  evaluation  of  proposals. 


3.2.1  CALS  Implementation  Plan  fCALSIPI 

The  CALS  Implementation  Plan  (CALSIP)  is  the  "roadmap*  for  contractor  CALS  implementation. 
The  CALSIP  should  be  required  no  later  than  the  DemonstratiorVVaiidation  phase.  This 
requirement  will  be  stated  in  section  L  of  the  RFP,  Instructions  to  Offerors.  The  RFP  instructions 
should  require  the  offeror  to: 

a)  identify  automated  capabilities  for  developing  and  integrating  data  (i.e.,  creating  data 
once  and  using  to  support  concurrent  engineering  cmd  other  processes. 

b)  describe  proposed  Contractor  Integrated  Technical  Information  Services  (CITIS;  see 
paragraph  3.2.2.1); 

c)  propose  changes  to  the  delivery  media  for  data  types  specified  in  the  GCO  and  CDRL, 
and  provide  anaiysis/justification  for  the  approach(es)  selected  for  delivery  of  digital  data; 

d)  describe  the  methodology  to  be  used  W  tracking  actual  versus  projected  cost  and 
berrefits  for  the  proposed  Ci^S  initiatives;  and, 

e)  outline  proposed  actions  and  capabilities  to  be  pursued  in  subsequent  life-cycle 
phases. 
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More  detailed  guidance  on  the  specific  content  of  the  CALSIP  can  be  found  in  MIL-HDBK-59A, 
section  5.1 .2.1 .1 . 

The  CALSIP(s)  submitted  should  be  evaluated  technicaliy  using  crtteria/factots  that  measure 
quality  and  schedule  in  fulfilling  RFP  CALS  requtrements  consistent  with  the  information  strategy 
and  capabilities  identified  in  the  GCO. 

In  some  cases  the  Acquisition  Manager  may  desire  defivery  of  detailed  CALS  implementation 
anaiyses^studies  in  support  of  the  program.  If  so.  the  Acquisition  Manager  should  dte  these 
requirements  separately  and  should  direct  the  formation  on  these  CALS  analyses  be  delivered 
in  accordance  with  the  appropriate  CORL. 


3.2.2  Dioltal  Access  and  Delivenr  of  infbnnation 

The  spectrum  of  delivery  optiorts  of  CALS  deliverables  ranges  from  paper  to  magnetic  t^)e  and 
optical  disk  media  to  on-line,  remote  termirtai  access  for  exchange  of  information,  in  order  to 
reduce  the  time  and  resources  required  to  review,  validats/verify  and  approve  corttractor  data, 
the  Acquisition  Manager  can  require  replacement  erf  formatted,  hard-copy  paper  deiiwerables  with 
digital  delivery.  Digital  information  dein^  would  indude;  1)  on-line  access  (CmS),  2)  specified 
formats  using  digital  media  (lAW  MIL-STD-1840  exchange  specification  or  mutually  agreeable 
software),  or  3)  a  combination  of  1  and  2.  These  requirements  must  be  included  in  block  16  of 
the  Contract  Data  Requirements  List  (CDRL),  DD  Form  1423,  or  appropriate  contract  exhibit  for 
the  respective  data  requirement 


3.2.2.1  Contractor  Integrated  Technical  Information  Service  fCITISi. 

ems  is  a  computer-based  sendee  that  draws  upon  integrated  technical  information  from 
throughout  a  contractor's  enterprise  to  support  the  product  development  process.  Instead  of 
program  and  product  documeritation  (typicaDy  paper  defiverables)  being  prepared  and  sent, 
program  and  product  information  may  be  view^  and  manipulate  at  workstations  across  a 
network  that  indudes  most  Government  data  users.  CITIS  provides  a  single  entry  point  for 
authorized  government  access  to  contractor-mairrfained  weapon  system  technical  data.  CITIS 
should  provide  remote  access  data  services  to  the  Acquisition  Manager  arxl  Government 
technical,  business  and  logistic  activities  respons&rie  for  review  arxf  approval  of  data.  CITIS 
services  should  also  provide  access  to  and  management  of  technical  niformation.  CITIS  may 
indude  communication  via  electronic  man. 

The  Act  jisition  Manager  ha.  the  option  to  specify  that  firm  CITiS  requirements  be  addressed 
and  price'' 'he  c'*erors  proposals;  or,  the  Acquisition  Manager  may  elect  to  have  the  offerors 
submit  for  CITIS  as  an  altemativB  to  traditionar  deiive^  of  technical  information 

during  contract  performance.  The  latter  offers  the  contractors  more  latitude  in  defining  the  most 
cost-effective  approach  for  digital  delivery.  Regardless  of  the  approach,  the  earlier  in  a  program 
acquisition  life  cycle  the  decision  to  employ  CITIS  is  made,  the  greater  the  potential  for  savings. 
MIL-F-CmS  (DRAFT),  a  specification  which  will  establish  uniform  government  functional 
requirements  that  can  be  tailored  to  defense  programs  for  the  acquisition  of  CITIS,  is  available 
from  your  Service  CALS  point  of  contact.  (NOTE:  MIL-F-CITIS  is  a  draft  document  currently 
receiving  a  coordinated  Service/Industry  review;  however,  the  specification  language  and 
guidance  contained  in  the  draft  document  can  be  extracted  and  tailored  for  use  in  developing 
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soiidtation  documents.  Assistance  should  be  oblHned  from  the  Service  CALS  poM  of  contact 
when  using  this  draft  CITIS  specification.) 


The  Acquisition  Manager  should  evaluate  contractor  proposals  for  CmS  to  support  program 
requirements,  beginning  with  responses  receivad  to  requiremmts  for  the  OEM/VAL  phase. 
CITIS  can  also  be  evaluated  as  a  streamlining  atemative  to  the  acquisition  of  vast  amoiaits  of 
individual  data  dr'verables.  In  addition  to  reducing  the  number  of  Copt's  by  on-^  access  to 
contractor  data,  benefits  from  CITIS  remote  access  data  services  may  also  include  reduction  of 
the  number  of  repositories  for  data;  reduction  of  cyde  times  through  orv-iine  review,  andysis  or 
approval  of  technical  data;  and,  reduced  overd  requirements  due  to  avallabitty  of  information 
from  a  single  source.  Acquisition  Managers  should  review  the  contractor's  plans,  policies  and 
procedures  for  CITIS  artd  plan  for  substantive  and  procedural  audits,  indudng  tests  and 
demonstrations,  to  ensure  co^ormance  to  requirements. 


32.2.2  PlQltal  Media  Potions 

CALS  standards  should  be  invoked  in  block  sixteen  of  the  CDRL,  or  appropriate  contract  6xhB>R, 
for  digital  delivery  of  support  products  (e.g.,  engineering  drawings,  technical  manuals).  The 
media  for  transfer  (magnetic  tape,  optical  disk,  ^.)  should  be  commensurate  with  Government 
receiving  system  requirements.  Some  digital  defiverables,  such  as  technical  reports  and  plannirtg 
docurrrents,  may  simply  be  acquired  by  sped^ing  acceptable  commercially  available  word 
processing  software  in  the  CDRL  and  identifying  the  rer^red  (GCO  compatible)  physical  media 
(most  fikely  a  floppy  disk). 


3.3  Evaluating  CALS  During  Source  Selection 

During  the  source  selection  process,  the  CALSiP  should  be  evaluated  by  program  office  arxi  staff 
personnel  capable  of  providing  a  cross-functional  review  of  the  submltt^  proposals.  The  criteria 
for  evaluation  of  the  proposals  should  ensure  a  level  playing  field  is  established  from  which  each 
offeror's  CALSIP  is  evaluated.  Acquisition  Managers  shcxild  provide  special  emphasis  and  give 
an  increased  consideration  (scoring  weighQ  to  proposals  demonstrating  Bfe-cycle  cost  reductions, 
quality  and  schedule  improvements,  and  program  risk  reduction  through: 

a)  Data  Automation.  It  must  be  emphasized  that  data  must  be  created  digitally  at  the 
earfiest  program  phase.  Failure  to  develop  data  digitally  early  in  a  program  can  lead  to 
costly  requirements  for  data  corrversion  in  later  phases. 

b)  Data  Integration/ConcurTenf  Engineering  (CE).  Proposals,  as  a  minimum  should 
demonstrate  an  understanding  of  CE,  and  addtiional  weight  should  be  given  to  those 
proposals  that  contain  plarts  to  integrate  the  generation  arxl  use  of  system  de»gn, 
engineering,  logistics  and  manufacturing  data. 

c)  Digital  Access  and  Delivery  of  Information. 

d)  On-line  Access  to  Analysis  and  Simuialion  Tools. 

The  Acquisition  Manager  may  also  wish  to  require  a  pre-award  demonstration  of  the  contractor's 
CmS  or  other  CALS-related  capability. 
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4.0  Summary 


In  support  of  new  and  emerging  programs,  DoO  and  the  Services  are  gradualy  developing 
several  functiorudly  common  systems  as  part  of  an  infrastructure  modernization  effort  to  manage 
and  use  digital  technical  Information.  The  Acquisition  Manager,  h  planning  an6  contractuaHy 
implementing  an  effective  CALS  strategy,  must  have  current  knowledge  of  these  as  wefl  as 
Service  specific  infrastructure  developmerTtB.  In  addition,  as  lessons  are  learned  on  initial  CALS 
implementation  efforts,  acquisition  lariguage  and  tailoring  guidance  wil  be  improved.  The  Service 
CALS  point  of  contact  wS  be  the  primary  focal  point  to  provide  this  type  of  information  and 
identify  CALS  knowledgeable  persomei  within  each  acti^  that  can  provide  more  detailed 
assistance  to  the  Acquisition  Manager. 

MIL-HOBK-59A,  sections  5.2.1 .4-5  provide  gudance  concerning  cost/benefil  analysis  and 
incentives  relating  to  implementation  Of  an  effective  CALS  strategy.  In  general,  the  Acquistion 
Martager  can  expect  that  CALS  implementation,  to  include  the  integration  of  design,  production, 
support  and  management  processes,  and  the  digttal  exchange  of  technical  informal  among 
functional  applications,  can  provide  the  following  types  of  program  benefits: 

a)  Reduction  in  paper  volurrte  (harfoGrtg  arxl  storage); 

b)  Faster  access  and  retrieval  of  more  accurate  information; 

c)  More  rapid  feedback  and  identification  of  potential  program  and  technicai  problenm; 

d)  Improved  compatibility  of  CAO/CAM/CAE  systems;  and, 

e)  Greater  flexibility  in  the  use  of  data  for  analysis  of  supportabQity,  producfoiKty, 

simulation/modeiling  of  performance  characteristics  and  evaluation  of  product 

improvements. 

This  integrated  product  development  enterprise  w3i  allow  for  more  rapid  identification  of  technicai 
risk;  allow  rapid  trade-offs  between  design,  manufacturing  and  support;  and,  improved  schedule 
by  eRminating  unrtecessary  deficiency  correction  activities. 

The  CALS  vision  of  the  future  is  focused  on  improved  processes  enabled  by  integrated 
irrformation  environments  and  information  networks  providing  orvfine  data  access.  The 
Acquisition  Manager  must  be  aware  that  CALS  is  evolving  process  changes  to  create,  manage 
and  use  data  that  is  more  accurate,  currerfi  and  readily  access  ble.  As  information  technology 
u;  J  technical  standards  for  information  exchange  are  improvec,  the  DoD  Acquisition  Manager 
wi!'  be  able  to  reduce  program  risks,  shorten  acquisition  cycle  time  and  more  effectively  mar'  ' 
each  new  program. 
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APPENDIXA 


CALS  POINTS  OF  CONTACT 

Office  of  the  Secretary  of  Defense 
OASO  (P&q  CALS 
The  Pentag^  Room  2B322 
Washington,  DC  20301-8000 
(703)  687-0051 
AUTOVON  227-0051 

United  States  Army 
DALO-ZB 

The  Pentagon,  Room  3S60 
Washington,  DC  20301-8000 
(703)614-3711 
AUTOVON  224-3711 


United  States  Navy 
OPNAV403 

The  Pentagon,  Room  4B546 
Washington,  DC  20350 
(20^683-6958 
AUTOVON  225-5274 

Uriited  States  Air  Force 

HQTRS,  Air  Force  Systems  Command 

ATTN:  PLXC 

Andrews  AFB,  DC  20334-5000 

(301)981-3915 

AUTOVON  858-3915 

Defense  Logistics  Agency 
DLA-Z  (DRDO) 

6301  Uttie  Rivw  Turnpike 
Beauregard  Square,  Suite  310 
Alexandria,  VA  22312 
(703)274-4210 
AUTOVON  284-4210 
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1.0  INTRODUCTION 


This  document  provides  guidance  to  acquisition  managers  and  others  who  have  an 
interest  in  appiying  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  to  the 
acquisition  of  data  products  in  support  of  defense  systems.  CALS  is  a  strategy  that  wW 
enabie  more  effective  generation,  exchange,  management,  and  use  of  digital  data  to 
si4>port  detense  systems  and  equipment  including  management,  design/engmeering, 
manufacturing,  logistic  support,  and  operations  data  The  primary  goal  of  the  CALS 
strategy  is  to  migrate  from  manual,  paper-intensive  defense  systems  operations  to 
integrated,  highly-automated  acquisition  and  support  processes.  The  overall  intent  of 
the  CALS  strategy  is  to  improve  systems  acquisition  and  product  support  efficiency  and 
quality.  The  CALS  target  is  an  integrated  information  environment  that  will  enable 
continuous  process  improvement  through  the  use  of  digital  technical  information. 

The  CALS  strategy  will  require  different  approaches  to  planning  and  contracting  for  the 
acquisition  of  d^ense  systems.  The  information  developed  by  contractors  in 
management,  design,  build,  and  support  functions  for  defense  systems  may  migrate  to 
a  paperless,  digital  data  delivery  and  access  system.  The  planning  process  for 
implementing  various  CALS  initiatives  such  as  Technical  Manual  Publish  on  Demand 
System  (TMPOOS),  Joint  Engirreering  Data  Management  Information  and  Control 
System  (JEDMICS),  and  Computer-Aided  Design  (Second  Acquisition)  (CAD-2)  needs 
to  include  the  development  of  a  strategy  for  the  creation,  management,  and  use  of  this 
digital  data 

To  provi^  potential  bidders  with  an  understanding  of  specific  user  needs  for  technical 
information  throughout  all  life-cycle  activities,  a  CALS  Government  Concept  of 
Operation  (GCO)  should  be  developed  and  included  in  the  Request  for  Proposals 
(RFP)  as  Government  Furnished  information  (GFI).  The  GCO  is  developed  by  the 
acquisition  management  team  with  input  from  other  Government  activities  involved  in 
the  life-cycle  support  of  the  defense  system. 

1.1  Purpose/Scope 

The  planning  process  for  acquiring  any  defense  system  needs  to  include  the 
development  of  an  information  strategy  aimed  at  taking  advantage  of  automation  and 
integration  capabilities.  This  strategy  would  employ  a  computer-based  environment  for 
generating  and  storing  unique  data  elemertts  only  once  and  yet  provide  multiple  access 
to  multiple  applications.  This  strategy,  depicted  in  the  form  of  a  GCO,  identifies  typical 
users'  needs  for  technical  data  throughout  ail  life-cycle  activities  of  defense  sy^ems 
management,  design,  manufacture,  and  support  functions. 

1.2  How  To  Use  This  Document 

This  document  is  intended  to  be  used  as  a  guide  for  creating  a  GCO.  A  structural 
approach  to  implementing  CALS  requirements  is  provided.  Figure  1  shows  the 
relationships  of  the  GCO  to  the  contracting  process  narrated  in  section  3.  Figure  2 
diagrams  the  process  required  to  determine  how  CALS  should  be  applied  to  the 
contract  deliverables.  Section  4  provides  the  general  requirements  and  considerations 
for  the  process  described  in  figure  2,  while  section  5  details  the  specific  process  for 
defining  the  data  type,  data  users,  data  utilization,  user  infrastructure,  data 
access/del'ivery  requirements,  data  format,  applicable  specifications  and  standards,  and 
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data  delivery  media  Section  6  provides  considerations  for  a  common  thread  that 
should  be  expressed  in  all  Department  of  Navy  CALS  GCOs. 

Questionnaire  templates  contained  in  exhibK  1  facilitate  part  of  the  process  in  the 
development  of  required  information  for  the  GCO.  These  templates  should  be  provided 
to  those  Navy/Marine  Corps  activities  that  are  anticipated  to  provide  support  to  the 
specific  program  for  which  GCO  is  being  developed.  This  will  aid  in  identifying  the 
capabilities  that  exist  and  their  supporting  infrastructure.  Exhibit  2  contains  a  sample 
GCO  and  a  sample  Data  Item  Desaiption  (DID)  for  a  CALS  Implementation  Plan 
(CALSIP)  discussed  in  section  3. 
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2.0  REFERENCES 


2.1  Acronyms 


A  complete  list  of  acronyms  used  throughout  the  desktop  guide  is  in  Appendix  A  The 
acronyms  used  in  this  section  of  the  guide  are  listed  below. 


ADMAPS 

AP 

ATIS 

CAC 

CA02 

CAE/CAO/CAM 

CALS 
CALS  RIC 
CALSIP 

ccmr 

CD-ROM 

CD! 

CDRL 

CGM 

cms 

CUN 
CSAR  ‘ 

DON 

□PARS 

DID 

DLA 

DoD 

DoDI 

DON 

DTD 

DVI 

ECP 

EDI 

EDIF 

EDIFACT 

EMD 

FCIM 

FIPS 

FOSI 

GCO 

GR 

GOSIP 

lETM 

IGES 

ILS 

ILS/LSA 

ILSP 

IWSDB 


Automated  Document  Management  and  Publishing  System 
Aquisition  Plan 

Advanced  Technical  Information  System 

Contractor's  Approach  to  CALS 

Computer  AicM  Design,  2nd  Acquisition 

Computer  Aided  Engineering/Computer  Aided  DesigrVComputer 

Aided  Manufacturing 

Computer-aided  Acquisition  and  Logistic  Support 
CALS  Resource  &  Implementation  Cooperative 
CALS  Implementation  Pian 

International  Consultative  Committee  on  Telegraphy  and 
Telephony 

Compact  Disk,  Read  Only  Memory 

Compact  Disk  interactive 

Contract  Data  Requirements  List 

Computer  Graphics  Metafile 

Contractor  integrated  Technical  Information  Service 

Contract  Line  Item  Number 

Configuration  Status  Accounting  Reports 

Defense  Data  Network 

Defense  Federal  Acquisition  Regulation  Supplement 

Data  Item  Description 

Defense  Logistics  Agency 

Department  of  Defense 

DoD  institute 

Department  of  Navy 

Document  Type  Definitions 

Digital  Video  Interactive 

Engineering  Chartge  Proposal 

Electronic  Data  Interchange 

Bectronic  Data  interchange  Forrr  at 

EDI  for  Administration,  Commerce,  and  Transport 

Engineering  and  Manufacturing  Development 

Flexible  Computer  integrated  Manutacturing 

Federal  Information  Processing  Standard 

Formatting  Output  Specification  Instances 

Government  Conceit  of  Operation 

Govemmerrt  Furnished  information 

Government  Open  Systems  Interconnection  Profile 

Interactive  Electronic  Technical  Manual 

initial  Graphics  Exchange  Spedftcation 

Integrated  Logistics  Support 

ILS/Logistics 

Integrated  Logistic  Support  Ran 
Integrated  Weapons  Systems  Data  Base 
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JCALS 

Joint  Computer-aided  Acqiisition  arKi  Logistic  Support 

JEDMICS 

Joint  Engineering  Drawing  Managem^  and 

LORA 

Level  of  Repair  Analysis 

LSA 

Logistic  Support  Analysis 

LSAP 

Logistic  Support  Anat^s  Plan 

LSAR 

Logistic  Support  Analysis  Record 

MACS 

Mutually  Agreeable  Commercial  Software 

MIS 

Management  Information  System 

MPT 

Manpower,  Personnel,  Training 

NADC 

Naval  Air  Development  Center 

NAVAIR 

Naval  Air  Systenrts  Command  Headquarters 

NAVNET 

Navy  Network 

NAVSEA 

Naval  Sea  Systems  Command  Headquarters 

NAWC 

Naval  Air  Warfare  Center 

NIMP 

Navy  Infrastructure  Modernization  Program 

mp 

Naval  Training  Plan 

NWC 

Naval  Weapons  Center 

NWS 

Naval  Weapons  Station 

OSI 

Open  Systems  Interconnection 

PHS&T 

Packaging.  Handling,  Stowage,  &  Transportation 

PMTC 

Pacific  Missile  Test  Center 

R&M 

Reliability  and  Maintainability 

RAMP 

Rapid  Acquisition  of  Manufactured  Parts 

RR5 

Request  for  Deviation 

RFP 

Request  for  Proposal 

RFW 

Request  for  Waiver 

SEMP 

System  Ertgineering  Management  Plan 

SGML 

Standard  Generalized  Markup  Lartguage 

SOW 

Statement  of  Work 

SPA 

Solicitation  Package  Automation 

SQL 

Structured  Query  Language 

T&E 

Test  and  Evaluation 

TOP 

Technical  Data  Package 

TEMP 

Test  and  Evaluation  Master  Plan 

TM 

Technical  Manual 

TMPODS 

Technical  Manual  Publish  on  Demand  System 

VHDL 

VHSIC  Hardware  Description  Language 

VHSIC 

Very  High  Speed  integrated  Circuit 

WAN 

Wide  Area  Network 

WBS 

Work  Breakdown  Structure 

WORM 

Write  Once  &  Read  Many  Times 

A 


2^  Oftfinitions 


0«finitions  of  terms  used  in  this  section  and  throughout  the  desktop  guide  are  in 
Appendix  A:  Definitions. 

Applicable  Documents 

Documents  referenced  in  this  section  and  throughout  the  desktop  guide  are  listed  in 
Appendix  A:  Applicable  Documents. 
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3.0  RELATIONSHIP  OF  THE  GCO  TO  THE  CONTRACTING  PROCESS 

The  GCO  generated  utilizing  this  guide  will  provide  potential  offerors  an  understanding 
of  specific  Government  user  needs  for  technical  irtfc^ation  throughout  all  relevant  life¬ 
cycle  activities  of  the  defense  system.  The  relationship  of  the  GCO  to  the  various 
contracting  steps  is  shown  in  figure  1. 


•  Modflcation  to  GCO 

•  ModHicatign  to  CAC 

•  com.  MocSfications 


Davalop  CALSIP  ter  Approval, 
Hiaquirad 

Upgrada  Mraatructura,  It  Raquirad 


FIGURE  1.  The  CALS  GCO  in  the  Navy/Maiine  Corps  Contracting  Process 

3.1  RFP  and  GCO  Release 


The  GCO  planning  process  should  start  as  earty  in  the  acquisition  process  as  possible. 
The  GCO  is  a  Government  document  that  is  prepared  during  the  acquisition  planning 
and  requirements  determination  activity  for  each  procurement  It  is  used  to  provide 
information  to  potential  offerors  about  the  Government  infrastructure  and  CALS 
implementation  strategy  for  defense  systems.  Development  of  a  GCO  will  help  ensure 
that  the  Government  receives  the  correct  version  and  formats  of  digital  data  products 
needed  to  acquire  and  support  a  defense  system. 

The  GCO  can  assist  the  Acquisition  Manager  in  determining; 

•  The  hardware  and  software  systems  the  Government  has,  or  is  developing,  to 
manage  and  use  the  data 

•  Data  users,  types  of  data,  frequency  of  use,  and  timeliness  of  data  access  or 
delivery  to  each  user 

•  Data  use  and  the  review  and/or  approval  processes  to  support  life  cycle 
functions 
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Users'  locations  and  their  primary  functions  in  support  of  the  defense  system 


•  Data  interchange  requiraments  inciuding  format,  media,  appiicabie  standards, 
and  existing  telecommunications  capabilities 

•  Access  autlKMizations  and  restrictions 

•  Data  acceptance  requirements  inciuding  data  format  and  content  of  dat^  and 
the  Government  processes  for  accepting  product,  processable,  or  Contractu’ 
Integrated  Technical  Information  Service  (CITIS)  data. 

A  flow  diagram  of  the  entire  process  is  shown  in  figure  2.  The  suggested  methodology 
to  determine  the  data  acquisition  requirements  as  diagrammed  in  figure  2  is  corttained 
in  section  4. 

3.2  Contractor  Proposal 

Referencing  the  QCO,  potential  bidden  wilt  be  retted  to  develop  a  Contractors 
Approach  to  CALS  (CAC)  in  their  prepared  responses  to  the  RFP.  The  CAC  is  a 
description  of  the  contractors  approach,  experiences,  and  successes  in  the  creation, 
management,  use,  and  exchange  of  digital  information  identifying  capability  in  the  area 
of  CALS.  The  CAC  can  then  be  evaluated  by  the  Government  durirtg  the  source 
selection  process.  If  CITIS  requirements  are  included  in  the  RFP,  the  contractor  should 
address  the  approach  to  CITIS  within  the  CAC.  See  section  4.5  for  a  more  detailed 
discussion  of  CITIS. 

Bidders  should  be  encouraged  to  identify,  witNn  their  CAC,  a  more  efficient  and  more 
cost  effective  data  strategy.  Section  L  of  the  RFP  can  also  be  used  to  offer  potential 
bidders  the  opportunity  to  review  the  GCO  and  the  RFP  data  requirements  and  propose 
alternative  forms  of  delivery  of  digital  data  products  and  information  services  that 
reduce  iife-cyde  costs  and  improve  business  processes. 

3.3  Proposal  Evaluation 

CALS  requirements  are  typically  included  in  the  Management  Element  of  a  proposal. 
Evaluation  criteria  for  CALS  in  general  and  the  CAC  may  be  derived  from  MIL-HDBK- 
59.  Information  in  the  CAC  is  used  to  gauge  the  risk  associated  with  the  contractor's 
ability  to  provide  the  digital  data  products  and  services  required  by  the  RFP. 

3.4  Negotiation 

Differences  in  concepts  of  operation  between  the  Goverrvnent  and  the  bidder  selected 
through  the  source  selection  process  become  the  subject  for  negotiation.  The 
agreements  reached  during  negotiation  become  the  basis  for  a  contract  that  triggers 
feedback  to  ail  Navy/Marine  Corps  acthrities  involved  in  the  support  of  the  defense 
system  and  subsequent  changes  to  the  GCO  and  perhaps  the  CAC.  Any  selected 
alternatives  proposed  by  the  contractor  must  also  be  Incorporated  into  the  contract  and 
appropriate  Contract  Data  Requirements  List  (CDRL). 
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3.5  Contract  Award 


The  solicitation  and  ensuing  contract  should  state  that  an  ot^ective  of  the  acquisition  is 
to  require  the  contractor  to  generate  information  products  for  ail  development  and 
production  functions  in  an  integrated  information  system  and  a  shared  data 
environment  to  the  maximum  extent  practicable,  ideally,  this  integration  should  be 
achieved  as  part  of  a  comprehensive  concurrent  engineering  strategy.  The  integrated 
environment  will  provide  for  generation,  storage,  indexing,  distribution,  access,  and 
delivery  of  digital  technical  data  products  in  support  of  defense  system  development 
and  production  functions  and  processes.  The  objective  is  to  create  each  data  element 
o  .}e  and  use  it  repeatedly  in  subsequent  processes  without  manual  reentry. 

Developing  this  integrated  environment  will  most  often  require  a  phased  approach  for 
implementation.  To  facilitate  a  phased  implementation  of  the  CALS  strategy,  the 
program  martager  may  wish  to  require  a  CALSiP  as  a  contract  deliverable  (typically  60 
days  after  contract  award)  that  is  maintained  throughout  the  life  of  the  contract.  In  such 
cases,  a  CALSiP  DIO,  which  is  in  the  process  of  being  approved  for  use,  will  be 
required. 
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4.0  BACKGROUND  INFORMATION  FOR  GCO  DEVELOPMENT 


The  GCO  must  provide  potential  bidders  an  understar>ding  of  specific  Goverrvnent  user 
needs  for  technical  information  throughout  all  relevant  lifc^de  activities  of  the 
defense  system.  The  GCO  must  be  thoroughly  developed  for  potential  bidders  to 
respond  with  a  proper  CAC.  Therefore,  the  acquisition  of  technical  data  by  the 
Navy/Marine  Corps  Program  Manager  requires  a  detailed  definition  of  data 
requirements.  The  effective  definition  of  these  technical  data  requirements 
necessitates  the  complete  identification  of  data  needs  and  uses.  Identification  of  these 
data  requirements  can  be  effectively  accomplished  through  the  use  of  a  well-defined 
process  described  in  4.1  •  4.8.  A  flow  chart  of  the  entire  process  is  shown  in  figure  2. 

1  IMnMyatMnWMat  X  Mn«yart*aM  X  MMSy  ■>■■■>  «Mr  «.  Maafy**  aMrV 


FIGURE  2.  GCO  Development  Process 


4.1  Identify  Data  Type  Deliverables 

Data  type  deliverables  are  the  data  requirements  specified  on  the  Contract  Data 
Requirements  List  (CDRL)  for  a  typical  program  categorized  by  program  function.  A 
survey  of  supporting  defense  system  activities  during  the  Requirements 
Determination/Data  Call  process  outlined  in  DoDI  5CXX}.2,  part  9,  section  B,  will 
establish  data  requirements.  Sample  data  types  to  be  digitally  developed,  accessed 
and/or  delivered,  and  maintained  are  listed  in  table  I.  Note  that  table  I.  is  not  intended 
to  be  all  inclusive. 
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TABLE  1.  Typical  Data  Type  Deliverables 


Management  and  Administration  Data: 

ILSA^A  Plans  and  Reports; 

•  Program  Plarts 

*  Program  Schedules 

•  Logistics  Support  Analysis  Plan  (LSAP) 

*  Engineering  Support  Plans 

•  Logistics  Support  Analysis  Record 
ILSAR) 

*  Progress  arrd  Status  ReportsAtaster 
Schedule 

•  Safety  Assessment  Reports 

*  Contractual  Vehicles 

•  Reliability  Assessment  Reports 

*  Conference  Agendas/Minutes 

•  MaintainabHIty  Reports 

*  Reviews  arKf  Audits  Documents 

•  Hazardous  Materials/Prooess  Reports 

*  Technical  Data  Identification  Checklists 

•  LSATasks(MIL-STD-1388-1A) 

*  Standardization  Program  Plan 

•  Maintenance  Plan/Reliability  Plan 

•  Contract  Work  Breakdown  Structure  (WBS) 

•  Maintainability  Plan 

■  Cost  Performance  Report 

•  Level  of  Repair  Analysis  (LORA) 

•  Management  Information  System  (MIS) 

Plan 

•  Test  and  Evaluation  Master  Plan 

*  Config.  Audit  Plan/Status  Accounting 

Report 

•  Test  Reports 

*  Data  accession  list 

*  Life  Cycle  Cost  Estimates 

*  System  Engineering  Management  Plan 
(SEMR 

•  Configuration  Managenrent  Plan 

•  CALS  Implementation  Plan  (CALSIP) 

•  Manufacturing  Plan 

• 

•  EnvironmentBl  Impact  Report 

Product  Description  Data: 

•  Technical  Report-Study  Services 

*  Technical  Data  Package 

•  Quality  Program  Plan 

*  System  Specifications 

•  Computer  Resources  Integrated 

Support  Document 

*  Engineering  Drawings  and  Associated  Lists 

*  Design  to  Cost  Ran 

*  Analysis  Data 

*  Simulation  Data 

Publications: 

*  Test  Data 

•  Technical  Publications 

•  ECP,  RFW,  and  RFD 

•  Technical  Manuals 

*  Product  Specification 

•  User%  Manuals 

*  Software  Development  Plan 

•  Operations  Manuals 

•  Software  Test  Plan/Descriptior\^eport 

*  System  Specification  Report 

*  System  Engineering  Analysis  Report 

*  Engineering  Data 

The  data  type  deliverables  should  be  categorized  by  discipline,  functional  activity,  or 
other  such  groupings  to  facilitate  a  standardized  approach  to  applying  the  CALS  digital 
data  standards  and  specifications.  Such  categori^ion  will  also  allow  the  Acquisition 
Manager  to  take  advarttage  of  common  Department  of  Navy  (DON)  infrastructure 
modernization  systems  and  business  process  improvements.  See  discussion  of  a  DON 
standardized  GCO  in  section  6. 
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Data  Users 

The  data  users,  as  shown  in  figure  2,  are  the  functional  organizations  that  will  require 
access  to  the  program  data  These  organizational  areas  include;  Acquisition, 
engineering/design,  supply,  training,  manufacturing,  and  maintenance,  in  addition  to 
their  functional  responsibilities,  these  organizations  are  defined  by  their  location  and 
the  specific  disciplines  involved.  See  exhibit  2,  table  3-1  for  an  example. 

4  J  Identify  Data  Use/Processing 

The  data  use  requirements  are  the  ways  in  which  the  chosen  data  types  may  be 
considered  for  processing.  The  Acquisition  Manager  will  need  to  identify  t  e  use  of  the 
data  types  by  the  support  organizations  chosen  for  the  program.  The  five  deHned 
methods  of  data  processing  typical  of  most  defense  systems  are  described  below. 

•  View  Only  •  the  ability  to  examine  a  data  file  without  the  ability  to  change  it  This 
includes  viewing  selected  portions  of  one  or  several  documents  as  welt  as  side- 
by-side  comparisons  of  documents. 

•  Commerrt/Annotate  -  the  ability  to  evaluate  and  highlight  fur  future  reference  or 
to  make  annotations,  approvals,  and  comments  without  the  ability  to  change  the 
original  file.  Annotations  are  associated  with  a  specific  item  or  location  virithin  a 
document  such  that  the  annotations  are  displayed  whenever  that  point  or  area 
of  the  document  is  displayed. 

•  Update/Maintain  -  the  ability  to  change  data  either  directly  or  through  controlling 
software  in  the  active  files  on  the  host  computer. 

•  Extract/Process/Transform  -  the  ability  to  extract  and  modify  the  format, 
composition,  and  structure  of  the  data  into  another  usable  form. 

•  Archive  -  the  placing  of  data  irtto  a  repository  to  preserve  it  for  future  use. 

4.4  Identify  Data  User  Infrastructure 

The  availability  of  digital  data  processing  and  telecommunications  technology  and 
approved  standards  for  creation,  storage,  transmission,  data  protection,  and  integrity  of 
at  the  time  of  delivery  or  access  are  important  criteria  for  acquisKion  decisions. 
The  current  and  projected  capabilities  of  both  the  contractor  and  Department  of 
Defense  (DoD)  components  [military  services  and  Defense  Logistics  Agency  (DLA)] 
must  be  assessed  with  respect  to  program  needs  and  schedules.  The  QCO  is  an 
excellent  vehicle  for  making  these  detemninalions.  Acquisition  Managers  should  plan  to 
access  or  acquire  digital  data  products  rather  than  hard  copy  unless  a  clear  caoe  can 
be  made  that  the  costs  will  outweigh  the  life-cycle  benefits. 

The  data  user  infrastructure  is  the  computing  environment  availabie  to  a  particular  user. 
This  environment  establishes  the  data  processing  capabilities  of  that  user.  The 
following  areas  identify  a  user's  infrastructure: 

•  Hardware:  Determine  the  current  and  planned  hardware  available  to  support 
the  program. 
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•  Software:  This  is  the  most  critical  element  Interoperability  will  normally  be 
achieved  through  the  use  of  software.  Again,  determine  both  present  and 
future  software  applications  and  availability. 

•  Networks:  Determine  the  local-  and  wide-area  networking  capabilities  and 
whether  CITIS  will  be  used. 

4.4.1  Navy  Infrastructure  Modernization  Programs  (NIMPs) 

The  Navy/Marine  Corps  are  building  various  CALS  supporting  systems  for  generation, 
receipt  and  processing  of  digital  data.  The  Acquisition  Manager  is  responsible  for 
determining  which  of  these  systems  will  be  used  to  support  the  program  for  digital  data 
To  provide  potential  bidders  with  a  better  understanding  of  how  the  data  will  be  used, 
the  NIMPs  should  be  briefly  described  in  the  GCO.  Contact  a  Navy/Marine  Corps 
CALS  point  of  contact  for  more  information.  Some  of  the  programs  are  briefly 
described. 

4.4.1 .1  Automated  Document  Management  and  Publishing  System  (ADMAPS) 

AOMAPS  is  a  contract  vehicle  that  provides  a  CALS  Standard  Generalized  Markup 
Language  (SGML)  publishing  system  for  the  acceptance,  verification,  creation,  and 
updating  of  TMs  and  other  Navy  documentation  delivered  from  contractors  or  authored 
within  the  Navy. 

4.4.1 .2  Advan^d  Technical  Infonnation  System  (AXIS) 

ATIS  is  a  preserrtation  system  designed  to  place  current  and  accurate  digital  technical 
data  into  users'  hands.  ATIS  allows  engineers  to  access  technical  documentation, 
retrieve  it  from  a  digital  repository  such  as  JEDMICS  (see  below),  and  create  technical 
information  files  containing  repair/planning  data.  Documerrtation  to  be  available  in 
ATIS  includes  engineering  drawings,  TMs,  preventive  maintenance  data,  and 
engineering  operating  and  sequencing  data 

4.4.1 .3  Computer  Aided  Design,  Second  Acquisition  (CAD2) 

CAO-2  provides  the  Navy  with  a  suite  of  necessary  off-the-shelf  equipment,  software, 
and  support  services  to  replace  time-consuming  manual  drafting  and  obsolete 
CAD/CAM/Cr^E  capat  inodem  computer  assisted  technology.  This  system 

will  be  enp!w^  .s  reate,  manage,  and  use  engineering  analysis  data,  engineering 
drawings,  technical  reports,  TMs,  technical  orders,  bid  packages,  manufacturing  data, 
product  models,  and  work  packages. 

4.4.1 .4  Joint  Engineering  Data  Management  information  and  Control  System 
(JEDMICS) 

JEDMICS  provides  a  standard  digital  system  for  storage,  retrieval,  reproduction,  and 
distribution  of  engineering  drawings  and  related  technical  data  to  support  defense 
system  maintenance,  reprocurement  of  spares,  engineering,  training,  manufacturing 
and  logistics  support. 
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4.4.1 .5  Tachnical  Manual  Publish^n-Demand  System  (TMPODS) 

TMPOOS  provides  storage  of  CALS  digital  files  for  output  on  demand  (paper/digital)  of 
Navy/Marine  Corps  TMs. 

4J  Identify  Data  Oeiivery/Accees  Method 

The  data  delivery/access  methods  are  the  ways  in  whidi  the  data  types  may  be 
accessed  or  delivered  during  the  life  cyde  of  the  program.  Digital  delivery  and  access 
requirements  are  specified  through  the  Statement  of  Work  (SOW),  the  CORL,  and 
specific  DIOs.  The  two  options  that  an  Acquisition  Manager  may  use  to  support  digital 
delivery  requirements  are  physical  delivery  and  orvline  delivery  via  telecommunications. 
Physical  delivery  includes  delivery  of  ma^ietic  tape,  magnetic  disk,  or  optical  disk  used 
to  transfer  CDRL  Kerns  to  a  Government  sKe.  On-line  delivery  may  be  achieved  via  two 
methods:  1)  delivery  of  CORL  Kerns  from  a  contractor  sending  system  to  a 
Government-receiving  system  via  telecommunications  download:  or  2)  in  place  delivery, 
which  allows  data  Kerns  to  be  stored  and  maintained  at  a  contractor  sKe  for  retrieval 
arKi  display  via  telecommunications  using  a  Goverrvnent  terminal,  personal  computer, 
or  workstation.  On-line  access,  as  distinguished  from  on-line  delivery,  refers  to  the 
situation  in  which  an  organization  accesses  data  Kerns  through  Cms  sendees  or  other 
similar  Information  management  services  as  negotiated  in  the  contract 

Following  are  types  of  digital  deliverables  supported  by  delivery  and  access  methods 
specified  by  Acquisition  Managers.  Detailed  information  to  assist  in  developing  CDRL 
specifications  for  these  deliverables  is  provided  in  appendix  D  of  MIL-HD6K-59. 

•  Composed  Products:  Human  interpretable  documents  in  digital  image  format. 
These  Kerns  cannot  be  further  processed  since  they  are  complete,  published 
entities.  Examples  of  data  products  that  could  be  delivered  or  accessed  in  this 
format  include  legacy  engineering  drawings,  technical  reports,  and  test  plans. 

•  Processable  Data  Ries:  Machine  readable  dynamic  information  that  includes 
revisable  source  data  for  multiple  data  applications,  thus  enabling  standard  and 
custom  documents  to  be  generated  and  the  source  data  to  be  manipulated. 
Examples  of  processable  files  are  LSAR  files  and  files  extracted  as  subsets  of 
computer-aided  design  files.. 

•  Interactive  Databases:  On-line  interactive  access  provides  greatest  fiexibiiity  of 
data  usage  with  immediate  and  timely  data  access  for  custom  report  generation, 
document  generation,  and  orvline  request  of  information  transmitted  as 
composed  products  and  processable  data  files.  Acquisition  Managers  should 
give  preference  to  use  of  CITIS  for  performing  the  functions  of  updating,  storing, 
controlling,  reproducing,  and  distributing  data  Kerns.  MIL-STD-974  provides 
information  concerning  core  CITIS  functions  and  tailorable  CITIS  functions, 
whidi  should  be  specified  in  the  SOW  and  listed  as  contract  line  Kerns. 

4.6  Determine  Data  Format 

The  following  data  formats  are  the  forms  in  which  each  of  the  delivery/access  methods 
can  be  procured.  Refer  to  figure  2  for  their  relationships  to  the  delivery/access 
methods. 
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•  Document  Image  RIe 

•  Text  File 

•  Graphics  File 

•  Alphanumeric  Re 

•  Audio/Visuai  RIe 

•  Integrated  Data  RIe 

4.7  Determine  Data  Interchange  Standards 

The  following  types  of  interchange  standards  are  used  with  data  formats  listed  in  4.6. 

•  Document  Image  Standards 
«  Text  Standards 

•  Graphics  Starxlards 

•  Application  Unique/Data  Standards 

4.8  Determine  the  Media  Type 

4.8.1  Physical  Media 

Magnetic  tape  is  a  mature,  stable  technology  that  is  abie  to  harxlle  the  large  volumes  of 
data  typically  associated  with  a  major  defense  system  acquisitioa  Magnetic  tape 
standards  are  well  defined,  and  little  additional  investment  cost  will  be  involved. 
However,  other  media  may  be  more  efficient  and,  therefore,  preferred. 

Magnetic  disk  is  also  widely  implemented  on  personal  computers  and  work  stations  and 
may  be  the  physical  medium  of  choice  for  small  business  contractors.  Several  primary 
de  facto  magnetic  disk  formats  are  available  but  no  official  standard  has  been 
accepted.  Compatibility  problems  exist,  but  can  be  overcome  with  only  moderate  effort 

Optical  media  is  used  here  as  a  generic  term  to  include  Compact  Disk,  Read  Only 
Memory  (CD-ROM),  Compact  Disk  Interactive  (CDl)  and  Digital  Video  Interactive  (DVI), 
Write  Once  and  Read  Many  Times  (WORM),  and  erasable  optical  disk.  These  media 
are  ideal  for  mass  distribution  and  archival  purposes  for  large  volumes  of  data 

4.8.2  Telecommunications 

Secure,  on-line  transmission  of  the  full  volume  of  data  for  defense  systems  is 
technically  feasible  but  severely  taxes  current  telecommunication  networks  in  DoD  and 
industry.  In  the  near  term,  telecommunications  may  be  limited  to  electronic  mail 
exchange  of  high-priority  technical  data  or  other  dearly  defined  uses  such  as  CITIS 
access.  In  the  long  term,  cost  effectiveness  will  be  essential  for  successful 
implementation  of  a  totally  integrated  defense  system  database. 

Telecommunication  networks  provide  an  excellent  opportunity  to  exchange  and 
establish  common  practices  for  business  type  data  using  Federal  Information 
Processing  Standard  (FIPS)  PUB  161  for  Electronic  Data  Interchange  (EDI)  standards. 
FIPS  PUB  161  summarizes  the  adoption  of  the  families  of  interrelated  software 
standards  known  as  ASC  XI 2  and  Electronic  Data  interchange  for  Administration, 
Commerce,  and  Transport  (EDI  FACT)  for  electronic  transmission  of  such  data.  The 
Acquisition  Manager  should  consider  taking  advantage  of  this  opportunity  for  program 
administration  process  improvements. 
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Upon  completion  of  the  GCO,  the  acquisition  management  team  will  be  prepared  to 
enter  the  solicitation  and  source  selection  process  with  a  firm  CALS  implementation 
strategy  and  krxjwiedge  of  the  needs  and  capabilities  for  acquiring  and  using  digital 
data 
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5.0  DATA  ACQUISITION  REQUIREMENTS  METHOD 


The  identification  of  infonnation  for  inclusion  in  the  GCO  is  described  in  the  following 
sections  and  shown  in  figure  2.  The  Acquisition  Manager  can  employ  and  adapt  this 
methodology  to  a  specific  acquisition  to  develop  the  program  requirements  for  digital 
data  delivery  or  access. 

5.1  Identify  Data  Type  Requirements 

The  Acquisition  Manager  will  need  to  select  the  data  types  listed  in  section  3.1  that  are 
necessary  to  accomplish  the  program  objectives.  Each  of  the  specific  types  of  data 
required  will  be  determined  by  the  unique  conditions  and  constraints  associated  with  a 
specific  program.  The  data  types  selected  will  ultimately  influence  data  format, 
interchange  standards,  and  media  considerations. 

The  best  method  for  determining  the  types  of  data  deliverables  required  is  to  extract 
the  data  deliverables  list  from  the  CDRL  and  to  categorize  the  data  types.  Table  1 
depicts  four  major  categories  of  data  types  in  terms  of  technical  functions  performed  for 
a  typical  defense  system  acquisition.  Table  2  illustrates  that  functional  areas  may  be 
categorized  in  more  detail  (training,  configuration  management)  to  help  in  determining 
which  supporting  activities  require  which  data  deliverables  to  perform  their  function(s). 

The  Acquisition  Manager  must  also  be  aware  of  the  various  NIMPs  that  are  in  place,  or 
soon  to  be  in  place,  to  accept,  manage  and  use  digital  data.  Any  data  deliverables  that 
will  require  updating  and  maintenance  throughout  the  life  cycle  of  the  defense  system 
(engineering  drawings,  TMs,  LSAR,  etc.)  are  excellent  candidates  for  digital  delivery 
and  making  use  of  the  NIMP  Systems.  These  systems  will  allow  for  a  more  common 
approach  aaoss  DON  for  developing  the  GCO.  See  section  6.  The  Acquisition 
Manager  should  certainly  take  advantage  of  these  systems  in  place  at  supporting 
Navy/Marine  Corps  activities  for  the  management  and  use  of  data  deliverables  in  digital 
formats.  See  4.4.1. 

5.2  identify  Data  Users 

The  Acquisition  Manager  will  need  to  identify  the  organ'ization(s)  requiring  data  and  the 
functions  of  the  organization.  Program  specific  conditions  and  constraints  will  determine 
which  organizational  areas  require  data  Once  the  required  organizational  areas  have 
been  determined,  the  name  of  the  organization,  the  organization''  function  (what 
services  they  provide),  the  location  of  each  organization,  and  the  Point  of  Contact  at 
each  organization  should  be  provided.  Table  2  is  an  example  of  data  users  for  a  typical 
program. 

This  information  provides  potential  bidders  with  an  understanding  of  the  separation  of 
work  functions  and  the  scope  of  geographic  locations  for  data  transmission 
requirements  or  other  modes  of  data  delivery  or  access.  An  added  benefit  from 
developing  the  Data  Users  Table  is  provided  to  the  Government  in  terms  of  clarifying 
the  functional  areas  required  to  support  the  defense  system  acquisition. 
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TABLE  2.  Data  Users 


Organlzatiofi 

Location 

Point  of  Contact 

OiadpUnas 
(Functional  Araas) 

NAVAIR 

Washington,  DC 

COR.  J.  Wilson,  Code  111 

S.  Spr^g,  Code  222 

J.  Baker,  Code  333 

B.  Mittie.  Code  444 

Program  Management 

Engineering 

Training 

Confiauration  Management 

NWC 

China  Lake,  CA 

B.  Smith,  Code  555 

Engineering  Support 

Logistics  Support 

PMTC 

Pt  Mugu,  CA 

R.  Ghese,  Code  777 

M.  Mahafee.  Code  839 

Logistics  Support 

Training 

NAOC 

Warminster,  PA 

J.  Jones,  Code  888 

NAWC 

Indianapolis,  IN 

E.  Farm,  Code  999 

NWS 

Yorktown.  VA 

0.  Bearman,  Code  32C 

■■■■■■■■I 

5^  Identify  Data  Us^rocessing 

The  Acqdisjtion  Manager  will  need  to  consider  how  the  data  will  be  processed  to  make 
decisions  on  digital  data  requirements  and  format.  The  five  categories  of  data  use 
listed  in  table  3  and  described  in  4.3  represent  typical  ways  the  data  types  can  be 
displayed  and  manipulated.  This  table  is  provided  as  a  guideline  to  show  how  the  data 
may  be  used  but  may  vary  depending  on  a  program's  requirements.  The  data  use 
requirements  may  be  influenced  by  the  data  user  selected  and  the  supporting 
infrastructure.  For  those  that  need  to  view  the  data  only,  a  word  processing  file  will 
suffice  for  most  data  types  in  lieu  of  paper.  As  users'  needs  become  more 
sophisticated,  such  as  a  need  to  annotate/excerpt  or  more  ImportarTtiy,  update/maintain 
or  process/transform  the  data,  standardized  digital  delivery  becomes  even  more 
essential.  The  Acquisition  Manager  will  need  to  match  the  digital  data  deliverables  to 
the  existing  or  planned  suite  of  equipment  that  makes  up  the  users'  infrastructure. 

5.4  identify  Data  User  Infrastructure 

To  assist  the  Acquisition  Manager  in  determining  the  user's  infrastructure  and  how  it  will 
affect  the  type  of  data  required,  a  data  acquisition  questionnaire,  exhibit  1 ,  has  been 
developed.  Responses  to  the  questionnaire  will  aid  in  giving  not  only  potential  bidders, 
but  also  the  Government,  a  clear  picture  of  the  supporting  infrastructure  in  place  to 
support  the  defense  system.  The  data  users'  irrfrastructure  or  data  processing 
environment  will  influence  several  areas  of  the  data  acquisition  process  including 
delivery/access  method,  data  format,  interchange  standards  for  the  data,  and  media  for 
data  delivery.  Since  each  supporting  activity  (data  user)  may  have  quite  different 
infrastructures,  the  Acquisition  Manager  will  need  to  be  aware  of  the  various  data 
requirements  imposed  by  the  different  infrastructures  and  make  attempts  to  bring 
commonality  to  the  suite  of  tools  available. 
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5^  Identify  Data  Delivery/Access  Method  Required 

The  Acquisition  Manager  will  need  to  identify  the  methods  by  which  data  win  be 
delivered  or  accessed  by  users.  Data  use  and  ^e  user  infrastructure  wiU  determine  the 
delivery/access  method  of  each  data  type.  If  available,  interactive  access  (CITIS) 
should  be  the  preferred  choice  of  delivery/access.  The  delivery/access  method  will 
influence  data  format,  interchang«>  standards  required  to  produce  and  exchange  the 
data,  and  media  for  data  delivery.  Table  3  is  an  example  of  data  delivery/access 
method  as  well  as  other  information  for  a  program. 

The  Acquisition  Manager  needs  to  determine  whether  the  data  delivery/access  method 
for  each  data  type  deliverable  falls  into  the  product  (documents)  classification, 
processable  data  files  classification,  or  interactive  access  (CmS)  dassificatioa  See 
figure  2.  Digital  data  deliverables  requiring  extensive  distribution,  frequent 
comment/update  cycles,  or  those  necessary  for  critical  program  management  decisions 
are  excellent  candidates  for  the  CITIS  environment  Other  deliverables,  especially 
those  which  would  be  unwieldy  in  data  file  size  (some  processable  data  files  such  as 
engineering  drawings)  should  probably  use  more  conventional  means  of  delivery  (MIL* 
STD-1840  tape,  magnetic  disks). 

Specific  data  formats  and  delivery  modes  will  be  stated  on  individual  DD  Form  1423 
CDRL  items.  Proper  safeguards  will  be  used  for  classified  information  (DOD 
5520.22M).  In  general,  the  following  formats  and  delivery  media  are  recommended  for 
each  data  type. 

•  Managemient  and  Administrative  Data:  This  data  should  be  available  through 
Cms.  On-line  management  status  data  should  be  analogous  to  that  available 
to  contractor  program  managers. 

•  Product  Description  Data  Initial  Graphics  Exchange  Specification  (IGES),  MIL- 
D-28000  format  with  delivery  in  accordance  with  MIL-STD-1840.  As  digital 
format  and  delivery  standards  are  introduced  for  additional  product  description 
data  (i.e.,  intelligent  product  data,  models,  etc.),  CDRL  delivery  requirements 
may  be  modified  appropriately. 

•  Integrated  Logistics  Support  (ILS)  /  Logistic  Support  Analysis  (LSA)  Plans  and 
Reports;  Mutually  Agreeable  Commercial  So^are  (MACS)  formats.  Text- 
based  documents  should  be  generated  in  a  commonly-used,  word  processing 
formal  Ancillary  graphics,  spreadsheets,  and  other  associated  data  files  should 
be  developed  in  common  business  software.  These  files  should  be  provided  as 
separate  files  in  their  native  formats  (as  specified  in  DO  Form  1423s)  as  well  as 
incorporated  into  a  master  document  It  is  preferred  that  these  files  be  delivered 
electronically  over  the  communications  network.  Depending  on  file  size  and 
communication  speed,  this  may  necessitate  MACS  file  compression  routines  or 
floppy  disk  delivery.  Relational  database  formats,  as  described  in  FIPS-PUB- 
127,  should  be  capable  of  being  accessed  via  Structured  Query  Language 
(SQL)  and  delivered  in  accordance  with  MIL-STD-1840.  LSAR  data  tables  will 
be  in  accordance  with  MIL-STD-1388-2B. 
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•  Publications:  Publications,  manuals,  specifications,  and  other  documentation 
that  will  be  updated  and  maintained  over  the  life  cycle  of  the  program  should  be 
develofsed  in  SGML,  MIL-M-28001.  with  graphics  in  Computer  Graphics  Metafile 
(CGM),  MIL-0-26003,  and  delivered  in  accordance  with  MIL-STD-1840. 
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Table  3.  Data  Requirements 


OMiTyp* 

Daflvfy/AcetBB 

Ualhod 

Fonrat 

■ 

MANAOEMENr  AND  AOMNSTRATION  DATA: 

Pregram  Plans 

1Z.S 

A.B.C.E.F.H.I 

a.b 

Enghtsartno  Support  Plant 

1Z.3 

A.B.C.E.F.H.I 

a.b 

ProofBM  and  Statn  Raports 

1Z.3 

mm 

Contract  Vahldat 

1Z.3 

A.B.C.E.F.H.I 

mm 

PRODUCT  OeSCRPTON  DATA: 

Ora«dnot/Asaoeiatad  Uttt 

B.D.6 

wsm 

ECP.  RFW,  RFD 

1Z.3 

A.B.C.E.F.HJ 

a.b 

_ _ 

A.B.C.4;.F.H.I 

warn 

Simulalion  Data 

1Z.3 

A.B.C.E.F.H.I 

a.b 

vOWuCWMDWi) 


k  Ti 


A. 


5.6  Identify  Data  Format  Required 

The  Acquisition  Manager  will  need  to  identify  the  data  format(s)  for  delivery,  which  is 
determined  by  the  delivery/access  method  described  in  5.5.  The  chosen  formats  will 
affect  interchange  standards  used  and  the  media  used  for  data  delivery.  Table  3  is  an 
example  of  data  format  as  well  as  other  information  for  a  program. 

There  is  little  benefit  to  receiving  hard  copy  deliverables  for  any  use  other  than  view 
only.  Realizing  that  most  data  generated  by  the  contractor  now  starts  out  in  some 
digital  format  (word  processing,  graphics  development,  spread  sheets,  CAO,  etc.),  the 
Acquisition  Manager  should  avoid  hard  copy  format  whenever  possible.  As  a  minimum, 
document  image  files  (printer  description  language  files)  should  be  considered  for 
distribution  in  lieu  of  hard  copy. 

Most  deliverables  generated  by  the  contractor  can  be  utilized  in  their  native  format 
(processable  data  files)  if  the  Government  has  a  compatible  suite  of  hardware/software 
or  a  CmS  environment  is  employed.  Also,  text,  graphics,  alphanumeric,  eujdio/visual, 
and  integrated  data  file  formats  lend  themselves  to  applying  the  CALS  standards  for 
data  interchange.  See  figure  2.  However,  it  may  not  be  cost  effective  to  apply  CALS 
standards  to  these  data  formats  until  the  final  deliverable.  For  example:  A  TM  will  go 
through  many  iterations  of  authoring,  review/comment,  editing,  and  distribution  before 
the  final  delivery.  Typically,  the  manual  is  being  developed  on  a  word  processor  or 
desk-top  publishing  system.  It  may  not  be  cost  effective  to  invoke  the  MIL'M-28001 
CALS  standard  until  such  time  that  the  Government  has  the  infrastructure  in-place 
(ADMAPS,  TMPODS,  see  4.4.1)  or  takes  final  delivery  of  the  document  and  thereby 
becomes  responsible  for  its  configuration  control,  archiving,  and  maintenance  of  the 
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document  Therefore,  the  Acquisition  Manager  may  want  to  take  advantage  of  the 
native  file  format  during  the  early  phases  of  the  contract  if  compatible  with  the  existing 
Government  infrastructure. 

5.7  Identify  Data  Interchange  Standard 

Each  of  the  data  formats  require  certain  interchange  standards  to  remain  CALS 
compliant  The  Acquisition  Manager  will  need  to  identify  the  interchange  standard 
required  for  each  data  format  However,  these  interchange  standards  will  vary 
depending  on  the  data  types  selected.  User  infrastructure  wOl  also  influence  which 
standards  will  be  invoked.  The  required  interchange  startdards  should  be  stated  in  the 
SOW  and  the  CORL  Table  3  is  an  example  of  data  interchange  standard  as  well  as 
other  information  for  a  program. 

5.8  Identify  Deliverable  Media 

The  Acquisition  Manager  will  need  to  determine  the  media  recMcAti  for  each  data  type 
selected.  Also,  the  Acquisition  Manager  must  consider  cost  when  determining  media 
delivery  due  to  the  large  volume  of  data  required  by  certain  data  types.  Other  factors 
wiH  Influence  deliverable  media  such  as,  the  deUvery/access  method(s),  data  format(s), 
and  interchange  standard(s)  required.  The  required  delivery  media  should  be  stated  in 
the  SOW  and  CORL  Table  3  is  an  ex»nple  of  data  delivery  media  as  wen  as  other 
information  for  a  program. 

Note:  The  CFTIS  environment  can  be  considered  a  media  for  access  and  should  be 
listed  on'Hhe  appropriate  CORLs  when  applicable. 
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EXHiBITI 


Data  Acquisition  Questionnairs 


The  following  questionnaire  will  assist  In  developing  a  GCO  that  will  be  used  to  tailor  a 
particular  acquisition  strategy  to  a  specific  program.  Depending  on  the  type  of 
acquisition,  sire  of  the  program,  and  the  phase  of  acquisition,  the  content  of  the 
program-specific  GCO  may  vary.  Each  program  will  require  and  have  access  to  its  ovm 
unique  infrastructure.  This  questionnaire  is  Intended  to  determine  the  infrastructure  In 
place/required  for  program-specific  si^port  See  1 .2. 
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PROGRAM  INFRASTRUCTURE  QUESTIONNAIRE 


The  following  information  is  designed  to  help  in  determining  the  hardware,  software  and 

networking  capabilitiesi/requirements  for  ttre  _ program.  This 

information  will  aid  in  determining  the  data  acquisition  strategy  for  this  program.  It  will 
be  used  to  develop  a  CALS  Government  Corrcept  of  Operation  (QCO)  and  will  be 
provided  in  an  RFP  to  potential  bidders  for  developing  a  CALS  Implementation  Ran. 
The  types  of  data,  delivery  method,  access  media,  mechanics  of  interchange,  an  j  use 
of  the  data  required  for  this  program  will  be  based  upon  your  responses  to  this 
questionnaire.  Please  fill  out  this  questionnaire  as  completely  as  possible  and  return  to 
the  program  office  no  later  than _ 

Questions  may  be  directed  to _ at 

PHONE: _ 

ADDRESS _ _ 


I.  Data  Requirements 


Check  each  data  type  and  its  intended  use  that  your  organization  requires  to  perform 
assigned  functions  in  support  of  this  program.  Definitions  for  the  di^rent  mearrs  of 
using  the  data  are  found  in  MIL-HDBK-59. 


Data  Type 

(V) 

(C) 

(p) 

(U) 

(A) 

•  Management  and  Administration  Data: 

•  Program  Plans 

•  Progress  and  Status  Reports/Master  Sdiedule 

•  Contractual  Vehicles 

•  Conference  Agendas/Minutes 

•  Reviews  and  Audits  Documents 

•  Technical  Data  Identification  Checkfists 

•  Standardization  Program  Plan 

•  Contract  Work  Breakdown  Structure  (WBS) 

•  Cost  Performance  Report 

*  Management  Information  System  (MIS)  Plan 

•  Configuration  Audit  Plan/Status  Accounting  Report 

•  Data  Accession  List 

•  System  Engineering  Management  Plan  (SEMR 

•  * 

(WViMr  only.  ^)«ConMMni/AnnalMe.  (P)>Exc*rpi^RKmrrraf«tonn.  (U)mUpiiaMMalnialn,  (A)*  Aichhw  ■fa  In  ottMn  nM  IMad. 
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(V)  (C)  I  (P)  I  (U)  I  (A) 


Data  Type 


Product  Description  Data: 


•  Technical  Data  Packa 


•  Svstem  SoecHications 


and  Associated  Lists 


Data 


*  Simulation  Data 


•  Test  Data 


•  ECP.  RFW,  and  RFD 


•  Product  Specification 


•  Software  Developmerit  Plan 


•  Software  Test  Pian/Descri 


ems  Specification  Report 


em  Enaineerina  Analysis  R 


Enoineerinq  Data 


(V)aVtaw  only.  (C)aCamniMl/!AnnaHla.  ^■EaBacpt^HsoM/riaMianB,  (U)aUpiMaAMnlain.  AidWa  *Fa  In  aMan  na  liund. 

IL  Hardware  Capabilities 

List  computer  and  peripheral  equipment  that  will  be  used  by  your  organization  in 
support  of  this  program. 


Hardware 


Personal  Computers 


Mainframes/Minis 


Check  the  appropriate  system  block  to  verify  whether  or  not  your  organization  has 
access  to  the  following: 

I  I  JCALS  System  I  I  JEDMICS  System 

CZ]  RAMP  Cells  □□  FCIM  Capability 

□  CAD2  Tool 
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III.  Software  Capabilities 


List  operating  systems  and  versions  used  with  hardware  described  previously. 
Describe  the  most  common  and/or  standard  commercial  software  products  that  have 
been  selected  by  your  organization  for  each  category.  Provide  version  numbers  if 
possible. 


28 


IV.  Network  Capabilities 

Describe  Local  Area  Network  capabilities  that  will  be  used  in  support  of  this  program. 
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V.  CALS  Raquiremwits 


Check  the  following  boxes  to  denote  your  organization's  familiarity  and  use  of  the 
following  standards/specifications. 


IGES  (MIL-n-28000) 

□□ 

IPC-D-350 

1  1 

SGML  (MIL-M-28001) 

CD 

lETM  (MIL-M-87268) 

n=3 

Raster  (MIL-R-28002) 

HD 

CGM  (MiL-D-28003) 

HD 

EDI  (FIPS-PUB-161) 

CZI 

VHDL  (ANSI/IEEE  1076) 

HD 

EDIF  (ANSI/EIA  548-1988) 

VI.  Point  of  Contact  and  User  Information 

List  all  users  requiring  access  to  on-line  contractor  generated  data  (CITIS)  in  support  of 
this  program. 


Code 

*Daity,  Weekly,  Biweekly,  Monthly, 

Bimonthly,  Quarterly,  Semiannually,  Annually 

CALS  Point  of  Contact  for  your  Organization  _ _ ^Code 
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EXHIBIT  2 


SAMPLE  GCO  DEVELOPED  WITH  AID  FROM 


THIS  GUIDE 


This  sample  GCO  is  intended  for  tutorial  purposes  only  and  does  not  necessarily  reflect 
any  real  or  implied  infrastructure,  program,  capabilities,  or  requirements. 

Actual  hardware,  software,  and  network  vendor  names  and  product  names  have  been 
removed  in  table  5-1.  in  an  actual  GCO,  vendor  names  and  product  names  including 
version  numbers  would  be  filled  in. 
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1.0  INTRODUCTION 


1.1  Purpos* 

This  document  is  provided  as  Government  Furnished  information  (GFI)  to  address  how 
the  Government  intends  to  use  data  associated  with  XXX  programs  in  conformance 
with  the  Comp"*9r-aided  Acquisition  and  Logistics  Support  (CALS)  strategy.  CALS  is  a 
strategy  that  will  enable  more  effective  generation,  exchange,  storage,  and  use  of  data 
for  defense  systems  and  equipment,  including  management,  plarming, 
desigrVengineering,  manufacturing,  logistic  support,  and  operation  data.  As  such,  this 
document  is  intended  to  give  participating  contractors  and  other  Government  activities 
an  understanding  of  the  CALS  approach  that  will  be  implemented  for  the  XXX  program. 

1.2  Scope 

The  policies  and  strategies  set  forth  in  this  document  are  applicable  only  to  the  XXX 
program.  The  concepts  contained  in  this  document  apply  to  all  types  of  data  and 
information  that  are  generated  by  contractors  and  by  the  Government  during  the  life 
cyde  of  the  XXX  program. 

1.3  Application 

This  Government  Concept  of  Operations  (GCO)  is  provided  to  Government  and 
contractor  activities  as  guidance  for  dieir  preparation  of  CALS-related  plans  and 
developrpent  of  CALS  capabilities.  Government  activities  should  use  this  document  in 
defining  their  partidpation  in  the  XXX  program.  Contractors  should  use  the  GCO  in 
conjunction  with  a  Request  for  Proposals  (RFP)  as  source  information  for  developing  a 
Contractor's  Approach  to  CALS  (CAC).  This  GCO  and  resulting  CAC  provides  a  basis 
for  further  Government  and  contractor  planning  for  Implementation  of  CALS  in  the  XXX 
program.  Participating  activities  are  encouraged  to  propose  beneficial  changes  to  the 
information  provided  herein  that  improve  operation,  increase  quality,  and  reduce  costs. 
The  GCO  is  provided  for  planning  purposes  and  should  not  t^  considered  as  a 
commitment  on  the  part  of  the  Government. 
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2.0  REFERENCES 


2.1  Specifications 

MIL‘0*28000  Digital  Representation  for  Ccvnmunication  of  Product  Data:  initial 
Graphics  Exchange  Specification  (IGES)  Applicatiorts  Subsets  and  Application 
Protocols 

MlL-M-28001  Markup  Requirements  and  Generic  Style  Specification  for  Electronic 
Printed  Output  and  Exchange  of  Text  SGML 

MIL>R-28002  Requirements  for  Raster  Graphics  Representation  in  Binary  Format 

MIL-D>28003  Digital  Representation  for  Communication  of  illustration  Data  CGM 
Application  Profile 

MIL-T>31000  General  Specification  for  Technical  Data  Packages 
MIL-M-38784  Manuals,  Technical:  General  Style  and  Format  Requirements 

2.2  Standards 

MIL-STD-100  Engineering  Drawing  Practices 

MIL-STD-974  Contractor  Integrated  Technical  Information  Service  (CITIS) 
MIL-STD>138F-1  Logistic  Support  Analysis 

MIL-STD-1388-2  DoD  Requirements  for  a  Logistic  Support  Analysis  Record 
MIL-STD-1840  Automated  Information  for  Technical  Exchange 
MIL-STD-1777  Internet  Protocol 
MIL-STD-1778  Transmission  Control  Protocol 

2.3  Federal  Information  Processing  Standards 

FIPS  PUB  127-1  Database  Language  -  Standard  Query  Language  (SQL) 

FIPS  PUB  146-1  Government  Open  Systems  lnt<^rconnection  Profile  (GOSIP) 

FIPS  PUB  161  Bectronic  Data  Interchange  (EDI) 

2.4  Handbooks  and  Manuals 

DOD  5520.22-M  Industrial  Security  Manual  for  Safeguarding  Classified  information 
MIL-HDBK-59  DoD  CALS  Implementation  Guide 
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3.0  DATA  REQUIREMENTS 


All  XXX  program  data  will  be  considered  for  generation  in  digital  format  This  goal  will 
be  achieved  through  an  orderly  procession  of  steps  where  each  deliverable  is 
evaluated  as  to  economic  feasibility,  intended  use,  frequency  of  use,  and  infrastructure 
of  users.  Understandably,  certain  data  deliveries  may  remain  in  hard-copy  formal  and 
may  be  considered  for  conversion  to  digital  form  when  justified  by  economic  and  usage 
factors. 

3.1  Data  Types 

Data  types  to  be  digitally  developed,  delivered,  and  maintained  include,  but  are  not 
limited  to,  the  following. 

•  Management  and  Administrative  Data  including  program  plan,  program 
schedules,  engineering  support  plans,  system  engineering  management  plan, 
configuration  management  dat^  cost  performance  report  financial  data, 
notifications,  requests,  general  communications,  etc. 

•  Product  Description  Data  including  desiga  analysis,  manufacture,  test  and 
inspection  information  typically  included  in  a  technical  data  package 
(engineering  drawings  and  associated  lists).  Product  description  data  also 
includes  data  requirements  for  DoD  parts  on  demand  infrastructures,  such  as 
RAMP  and  FCIM  initiatives. 

•  ICS/LSA  Plans  and  Reports  including  Logistic  Support  Analysis  Record  (LSAR) 
data,  LSAP,  ILSP,  LORA,  configuration  management  plan,  reliability  and 
maintainability  data,  and  other  data  for  plans  and  reports. 

•  Publications  including  technical  publications,  technical  manuals,  User's 
manuals,  training  materials,  and  operation  manuals. 

3.2  Data  Use 
3.2.1  Data  Users 

Table  3-1  provides  an  overview  of  the  users  that  are  involved  with  and  require  access 
to  XXX  program  datsi,  their  location,  and  their  general  data  requirements. 
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TABLE  3-1 .  Data  Users  Associated  with  XXX  Programs 


ACTIVITY 

LOCATION 

FUNCTION 

1  DATA  REQUIREMENTS 

A,F  Materiel 
Command 

WP  AFB 

Dayton,  OH 

Design  Agent 

Engirteering  Data 

Engineering  Drawings 

R&M  Data 

Reports/Plans 

ILS 

LSAR  Data 

Tech  Pubs 

RepoiWPIans 

R&M  Data 

Provisioning  Data 

ILS/LSA  Data 

Training 

Training  Planning  Data 
Manpower  Rqmts  Data 

Training  Materials 

Aviation  Army 

Systems 

Command 

St.  Louis,  MO 

ILS  Support 

LSAR  Data 

Tech  Pubs 

Reports/Plarts 

Design  Data 

Training 

Training  Materials 

Aeronautical 

Systems 

Center 

WP  AFB 

Dayton,  OH 

Engineering  Support 
(Safety  Interface) 

R&M  Data 

Reportsi/Pians 

Engineering  Data 

Engineering  Drawings 

Quality  Assurance 

ILS/LSA  Data 

Technical  Pubs 

Maintenance  Data 

Engineering  Support 
(Avionics  &  Software) 

Engineering  Data 

Reports/Plans 

Engineering  Support 
(Vehicle  Dvnamics) 

Engineering  Data 

Reports/Plans 

MP&T 

Hardman  Data 

Training  Planning  Data 

Trmning  Material 

Technical  Publications 

Army  Materiel 
Command 

Alexandria,  VA 

T&E 

(Joint  Test 

Coordination) 

Engineering  Data 

Engineering  Drawings 
Reports/Plans 

Test  Plans 

Test  Reports 

Tech  Pubs 

Technical  Illustrations 

T&E  Training 

T raining  Planning  Data 

Training  Materials 

Manpower  Rqmts  Data 
Reports/Plans 
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TABLE  3-1.  Data  Users  Associated  with  XXX  Programs  (coni) 


ACTIVITY  I  location 


FUNCTION 


Data  Arudysis 


Ertgineering  Support 
(SAV) 


Technical  Data 


In-Process  Review 


Depot  Planning 


Logistics  Data  Analysis 


Washington,  DC  InstallatiorVIntegration 
Logistics  Data  Analysis 


MPT 


Hardman/NTP 


Training  Devices 


Financial 


Fadlities 


ILS  Support 


DATA  REQUIREMENTS 


Engineering  Data 
Test  Data 
RAM  Data 
CWQEData 

Data 


Engineering  Data 
Engineering  Drawings 
Ians 


Tech  Pubs 

Technical  Illustrations 


I Jiiv  iT :  tw  i. 


TDP  Elements 

Engineering  Dwgs,  Assoc.  Lists 
A  Related  Documents 


Provisionina  Data 


ILS/LSADaU 
Tech  Pubs 
Maintenance  Data 


ILS/LSAData 
Engineering  Data 
Test  Data 
Operational  Data 


Installation  Control  Dwgs 
ILS/LSAData 


Hardman  Data 


Training  Planning  Data 
Manpower  Rants  Data 


Engineering  Drawings 
Engineermg  Data 
Tech  Pubs 

Training  Planning  Data 
Trainina  Materials 


Cost  Data 

Expenditure  Reports 


FacOities  Data 
Maintenance  Data 


LSAR  Data 
Tech  Pubs 
Reports/Plans 


NOTE:  Typical  activities  are  shown  in  above  table. 
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3^^  Us«  Requirements 

The  data  use  requirements  are  the  ways  in  which  the  program  data  will  be  used  and/or 
processed.  The  five  defined  methods  of  data  processing  typical  of  the  XXX  programs 
are  described  below. 

•  View  Only:  The  ability  to  examine  a  data  file  without  the  ability  to  change  it 
This  includes  viewing  selected  portions  of  one  or  several  docum«its  as  well  as 
side-by-side  comparisons  of  documents. 

•  Comment/Annotate:  The  ability  to  evaluate  and  highlight  for  future  referertce  or 
to  make  annotations,  approvals,  and  comments  without  the  ability  to  change  the 
original  file.  Annotations  are  associated  \Amh  a  specific  Item  or  location  within  a 
document  such  that  the  annotations  are  displayed  whenever  that  point  or  area 
of  the  document  id  displayed. 

•  Extract/Process/Transform:  The  ability  to  extract  and  modify  the  format, 
composition,  and  structure  of  all  or  a  portion  of  the  data  into  another  usable 
form  without  affecting  the  original  content  or  format 

•  Update/Maintain:  The  ability  to  change  data  either  directly  or  through  controlling 
software,  in  the  active  files  on  the  host  computer.  (Contractor-maintained  XXX 
technical  data.) 

•  Archive:  The  placing  of  data  irrto  a  repository  to  preserve  it  for  future  use. 
(263R  ta^k) 

Table  3-2  provides  a  sampling  of  contract  data  typical  of  an  XXX  program  by  data  type 
and  depicts  how  the  data  is  intended  to  be  uscld.  This  list  is  not  intended  to  be  all 
inclusive;  rather  it  leads  to  a  decision  point  for  the  format  and  delivery  mode  of  the  data 
deliverables.  Data  Item  Descriptions  (DIDs)  used  are  typical  DIDs  but  are  not  intended 
to  be  all  inclusive. 

Note:  Two  or  more  methods  may  be  required  by  a  single  user.  The  methods  are  not 
mutually  exclusive. 
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Table  3*2.  XYZ  Programs  contract  Data  Use  Requirements  Sample  (Cont.) 
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KTranalenn 


3.3  Data  Delivery/ Access  Media 

Specific  data  formats  and  delivery  modes  shall  be  stated  on  individual  DD  Form  1423 
Contract  Data  Requirements  List  (CORL)  items.  Proper  safeguards  will  be  used  for 
classified  information  (DOD  5520.22M).  In  general,  the  following  formats  and  delivery 
media  are  recommended  for  each  data  type. 

•  Management  and  Administrative  Data:  This  data  should  be  available  through 
CITIS.  On-line  management  status  data  should  be  analogous  to  that  available 
to  contractor  program  managers. 

•  Product  Description  Data:  Initial  Graphics  Exchange  Specification  (IGES),  MIL- 
D-26000  format  with  delivery  in  accordance  with  MIL-STD-1840.  As  digital 
formal  and  delivery  standards  are  introduced  for  additional  product  description 
data  (intelligent  product  data,  models,  etc.),  CDRL  delivery  requirements  may  be 
modified  appropriately. 

•  ILS/LSA  Plans  and  Reports:  Mutually  Agreeable  Commercial  Software  (MACS) 
formats.  Text-based  documents  should  be  generated  in  a  commonly  used  word 
processing  format  Ancillary  graphics,  spreadsheets,  and  associated  data  files 
should  be  developed  in  common  business  software.  These  files  should  be 
provided  separately  in  their  native  formats  (as  specified  in  DD  Form  1423s)  as 
well  as  incorporated  into  a  master  document  It  is  preferred  that  these  files  be 
delivered  electronically  over  the  communications  network.  Depending  on  file 
size  and.  communication  speed,  this  may  necessitate  MACS  file  compression 
routines  or  floppy  disk  delivery.  Relational  database  format,  as  described  in 
Federal  Information  Publications  Standards  (FIPS)  PUB  127,  is  capable  of  being 
accessed  via  Structured  Query  Language  (SQL)  and  delivered  in  accordance 
with  MIL-STD-1840.  LSAR  data  tables  will  be  in  accordance  with  MIL-STD- 
1388-2B. 

•  Publications:  Publications,  manuals,  specifications,  and  other  documentation 
that  will  be  updated  and  maintained  over  the  life  cycle  of  the  program  should  be 
developed  in  Standard  Generalized  Markup  Language  (SGML),MIL-M-28001, 
with  graphics  in  Computer  Graphics  Metafile  (CGM),  MIL-D-28003,  and 
delivered  in  accordance  with  MIL-STD-1840. 

3.3.1  Preliminary  Format  and  Media  Recommendations 

Since  Plan/Report  data  types  are  most  common,  MACS  formats  will  typically  be  most 
frequent.  Although  electronic  deliveries  are  preferred,  these  may  be  limited  by  the 
netvrork  speed  and  file  size.  Therefore,  delivery  by  floppy  disk  is  recommended  for 
MACS  deliverables  that  would  overburden  the  network.  As  CITIS  capabilities  and  XXX 
program  network  performance  are  increased,  more  MACS  deliveries  can  be  made  over 
the  network  than  by  disk.  Nine-track  tape  in  accordance  with  MIL-STD-1840  is 
recommended  for  MIL-28000  Series  format  deliverables.  The  MIL-SPEC  28000  Series 
provides  implementation-specific  guidance  for  preparation  of  text  and  graphic  data  files 
for  technical  publications  or  product  data  interchange.  These  standards  are  relevant 
for  the  preparation  of  files  that  are  used  in  MIL-STD-1840  but  can  also  serve  many 
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other  data  transfer  and  neutral  language  format  purposes.  This  set  of  standards 
defines  how  technical  data  is  to  be  represerrted  digitally  in  a  number  of  different 
formats. 

With  the  overall  goal  of  CALS  to  migrate  toward  a  "digital*  envirorvnent,  MIL-STD*1840 
orchestrates  the  use  of  the  MIL-SPEC-28000  Series  and  is  one  of  the  fundamental 
standards  for  digital  data  interchange  of  textual  and/or  illustratiort/engineering  drawing 
information.  Once  the  acquisition  of  the  data  has  been  resolved,  it  is  MIL-STD-1840 
that  defines  the  process  for  how  the  technical  data  is  to  be  transferred. 

The  MIL-SPEC-28000  Series  provides  impiementatiorvspecific  guidance  for 
preparation  of  text  and  graphic  data  files  for  technical  publications  or  product  data 
interchange.  MIL-D-28000  defines  the  technical  requirements  necessary  to  acquire 
product  definition  data  or  product  data  in  a  neutral  public  domain  digital  format.  This 
specification  provides  a  neutral  format  (IGES)  for  the  representation  and  transfer  of 
vector  graphics  data  used  for  illustration  purposes  among  Computer  Aided  Design 
(CAO)  systems  and  application  programs  used  by  DoD  and  Industry.  MIL-M-28001 
defines  a  standard  for  preparation  of  text  information  for  technical  publicatiorts.  MIL-M- 
28001  SGML  is  a  text  mark-up  language  that  is  formatted  by  various  Document  Type 
Definitions  (DTDs)  and  Formatting  Output  Specification  instances  (FOSis)  which  define 
format  and  structure  of  the  text  output  MIL'R-28002  defines  the  technical 
requirements  necessary  to  acquire  raster  graphics  data  and  raster  graphics 
applications.  Raster  data  is  presently  providing  a  means  of  converting  legacy  technical 
data  into  a  digital  format  MIL-D-28003  defines  a  standard  to  be  met  when  vector- 
oriented  picture  descriptions  of  illustration  data  are  delivered  in  the  digital  format  of  the 
CGM.  ‘ 

Specific  MACS  products  have  not  been  finalized  but  will  include  popular  word 
processing,  spreadsheet,  database,  prqect  management,  and  graphics  programs. 
These  programs  are  commonly  found  in  both  Government  and  contractor  offices  and 
typically  support  conversion  from  one  format  to  another. 

Contractor  Format  and  Media  Recommendations 

The  contractor  is  encouraged  to  identify  and  describe  alternative  formats  and  delivery 
media  options  offering  increased  utility  and  cost  effectiveness.  These  formats  should 
be  compatible  with  the  infrastructure  and  data  formats  described  in  table  5-1.  in 
determining  suitability  of  a  particular  formal  or  media  option,  the  contractor  should 
consider  the  lifetime  and  purpose  of  each  deliverable. 

Relatively  short-lived  data  such  as  agenda,  minutes,  planning,  schedules, 
spreadsheets,  plans,  and  progress  reports  should  be  developed  in  MACS  products 
commonly  used  by  all  participants  of  file  XXX  programs.  Involved  contractors  should 
review  fiie  tools  utilized  by  the  Government  for  such  purposes  (see  section  5). 
Corrtractor  responses  in  their  CALSIPs  will  help  determine  the  method  utilized  to 
exchange  data  between  the  Government  and  the  contractor. 

Long-lived  data  such  as  engineering  drawings,  Logistics  Support  Analyst  Record 
(LSAR),  and  technical  publications  are  excellent  candidates  for  digital  delivery  in  the 
CALS  standards  and  specifications  formats.  These  items  are  archived  for  long-term 
storage  and  protection  for  future  developmental  changes  and  support  purposes. 
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Whenever  possible,  the  government  and  contractor  CALS  planning  should  focus  on 
development  of  data  in  a  digital  format  regardless  of  use.  This  will  assist  in  er^iing 
that  a  future  capability  for  delivery  and  processing  of  digital  source  data  is  retained. 
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4.0  cms 


Implementation  of  the  CALS  initiatives  for  XXX  program  will  require  establishment  and 
use  of  CITIS  to  provide  Government  access  to  contractor-maintained  data  supporting 
the  XXX  program.  CITIS  should  include  data  managemerrt,  security,  communicatiorts, 
and  other  attributes  necessary  to  fully  integrate  the  contractor's  XXX  program 
databases  with  the  Government  user's  database.  Additionally,  CITIS  should  be 
capable  of  storing  GFI  provided  to  the  contractor.  These  senrices  should  be  addressed 
in  the  CAC.  On  the  basis  of  information  in  the  bidder's  CAC,  the  Government  will 
determine  the  extent  that  the  contractor's  proposed  CITIS  capabilities  provide  cost- 
effective  use  of  Government  and  contractor  resources. 

4.1  CITIS  Capabilities 

Contractually  required  CITIS  capabilities  will  be  stated  in  the  c''~'ract  Statement(s)  of 
Work  (SOW).  However,  contractor  participants  in  the  XXX  programs  should  consider 
establishment  of  CITIS  capabilities  that  add  value  to  their  current  efforts.  The  CITIS 
services  shall  include  data  managemerrt,  security,  telecommunications,  and  other 
attributes  necessary  to  fully  integrate  the  contractor's  XXX  database  with  the 
Government  user's  databases.  MiL-STD-974  defines  functional  requirements  for 
CITIS.  There  are  some  capabilities  that  should  be  implemented. 

•  On-line  access  to  contractor-maintained  databases  containing  management, 
financial,  engineering,  and  logistics  program  data.  On-line  access  to  databases 
should  allow  users  to  perform  searches  on  data,  make  comments  on  data, 
produce  and  run  preformatted  (standardized)  reports  with  output  at  their 
location,  produce  ad-hoc  reports  with  output  at  their  location,  and  download 
selected  data  to  their  location  for  use  in  further  processing. 

•  On-line  access  to  contractor-developed  or  owned  applications.  This  capability 
should  allow  authorized  users  to  run  contractor-hosted  applications  from  remote 
computers  or  terminals.  These  applications  may  include  modeling,  simulations, 
analysis,  and  other  programs  that  provide  Government  users  with  insight  into 
the  contractor's  current  engineering,  logistics,  and  management  efforts. 

•  File  transfer  ability.  This  capability  should  allow  users  to  download  contractor 
data  files  (CORL  data  files  and  other  information  files).  This  capability  should 
also  allow  users  to  upload  data  files  to  the  contractor  (for  GFI  and  information 
requests). 

•  Electronic  mail  capability  compatible  with  the  Government  E-Mail  system(s). 
This  may  require  communications  to  a  centralized  mail  server  or  use  of 
compliant  E-Mail  packages.  GOSIP  is  the  preferred  government 
communications  protocol.  FIPS  PUB  146-1  provides  information  concerning 
GOSIP. 

4.2  CITIS  Data  Formats 

CITIS  data  satisfying  a  CDRL  requirement  should  be  formatted  to  include  content 
specified  by  the  DID.  CITIS  data  required  as  a  result  of  the  SOW  should  include  SOW 
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specified  data  in  a  logical  and  acceptable  format  and  be  easily  accessible.  The  content 
and  format  of  other  CITIS  data  proposed  by  the  contractor  should  be  in  a  format 
consistent  with  the  use  requirement 

4  J  Delivery  Criteria 

Contractor  data  provided  in  CITIS  as  a  result  of  a  CDRL  wfli  be  considered  delivered 
upon  acceptance  and  approval  by  the  requiring  office.  Other  CITIS  data  is  not 
considered  as  a  "deliverable'  but  is  maintained  by  the  contractor  in  accordance  with 
update  and  availability  requirements  specified  by  the  contract 

4.4  Government  Access 

CITIS  capabilities  will  be  accessible  by  the  Government  from  existing  terminals, 
personal  computers,  and  workstations.  The  Government  inteitds  to  establish 
permanent  communications  between  the  Governments  communications  ne*'.vork  and 
the  contractor  sites.  The  exact  implementation  of  these  communications  will  deperKi  on 
frequency  of  access,  cost,  data  volume,  and  other  factors.  Afl  communication  methods 
proposed  must  be  compliant  with  GOSIP. 

4.5  Data  Protection  and  Security 

CITIS  capabilities  must  include  means  to  ensure  only  authorized  access  to  and  update 
of  information  contained  within.  Data  associated  with  each  XXX  program  will  be  subject 
to  authenticatiorr  and  regular  backup.  Periodically,  backups  will  be  delivered  to  XXX 
program  Government  service  centers. 

Methodologies  to  handle  classified  data  have  not  been  fully  determined.  It  is  expected 
that  authorized  XXX  program  users  will  have  access  to  classified  information  over 
CmS  using  encryption  and  decryption  devices.  Until  such  time  that  these  devices  are 
determined,  classified  material  should  be  delivered  (in  digital  and  hard>copy  format) 
through  conventional  means  (U.S.  Mail). 

4.6  Data  Rights 

Rights  in  technical  and/or  business  data  proposed  for  or  available  via  CITIS  should  be 
negotiated  in  accordance  with  DFARS  252-227-7013. 
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5.0  DESCRIPTION  OF  GOVERNMENT  INFRASTRUCTURE 

This  section  describes  the  XXX  program  infrastructure  that  participating  activities  and 
contractors  should  consider  in  determining  format  and  communication  capabOities.  This 
data  is  provided  to  allow  program  participants  to  understand  the  capabilities  of  other 
users  and  to  make  informed  decisior^  regarding  options  and  capabilities  that  will  be  or 
could  be  established  to  support  the  XXX  program(s). 

5.1  User  Capabilities 

Table  5*1  describes  a  sample  of  the  hardware,  software,  and  communication  network 
capabilities  that  each  user  activity  would  typically  have  currently.  This  information  is 
not  intended  to  be  all  inclusive;  rather  It  gives  prospective  offerors  a  general  insight 
into  the  infrastructure  in  place  to  support  the  programs  including  hardware,  software, 
and  networkirrg  capabilities  of  XXX  program  activities.  This  information  will  be  updated 
as  user  automatic  data  processing  equipment  changes. 
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TABLE  5-1.  XXX  Program  User  Capabilities 


FUNCTION 

HARDWARE 

SOFTWARE 

NETWORKS 

Program 

Management, 

Configuration 

Management 

-  Vendor  B, 

Type  1 

-  Vendor  A, 

Type  1 

-  Venc  .  A 
APs/w1,2,&3 

-Vendors 

AP  s/w  1,2,3,&  4 

-  Vendor  C 

APa/wr1 

-  Vendor  A 

Type  1 

-  Vendors 

Typel 

Class  Desk 

-  Vendor  A, 

Type  1 

-  Vendor  A 

APsAvl 

-  Vendor  B 

APs/w  1  &4 

-  Vendor  D 

APa/wl 

-  VefKior  A 

Typel 

-  Vendor  B 

Typel 

-  Vertdor  C 

Typel 

ILS 

-  Vendor  B, 

Type  1 

-Vendor  A 
APs(w2&5 
-  Vendors 

APsAv2 

-Vendors 

APs/w1.2&3 

-  Vendor  B 

Type  1 

-  Vendor  D 

Type  1 

Training 

•  Vendor  B. 

Type  1 

-  VefKior  A 

APs^v2,  5,&6 

-Vendors 

APs/w2 

-  Vendor  C 

APs/wl 

-  Vendor  E 
APS/W1.2&3 

-Vendor  B 

Type  1 

-  Vendor  C 

Type  1 

-  Vendor  E 

Type  1 

PHS&T 

•  Vendor  B, 

Type  1 

-  Vendor  A 

APs/w6 

-  Vendor  C 

AP  s/w  1 

-  Vendor  E 

APs/wl  &2 

-  Vendor  G 

APs/w1 

-  Vendor  C 

Type  1 

Participating 
Matrix  Codes 
(Engineering, 

Cost  Analysis, 

Product 

Assurance) 

-  Vendor  B, 

Type  1 

-  Vendor  A, 

Type  1 

-  Vendor  C 

Type  1 

Type  2 

Type  3 

-  Vendor  A 
APs/w1,2,&5 

-  Vendor  E 
APs/w1&2 

-  Vendor  G 

APs/w2 

-  Vendor  H 

AP  s/w  1 

-  Vendor  1 

APs/wl 

-  Vendor  J 

AP  s/w2 

-  Vendor  K 

AP  s/w  1 

-  Vendor  B 

Type  1 

-  Vendor  E 

Type  1 

TABLE  5-1.  XXX  Program  User  Capabilities  (coni) 


USER 

FUNCTION 

HARDWARE 

SOFTWARE 

NETWORKS 

Program  Office, 
Engineering 

-  Vendor  A, 

Type  2 

-  Vertdor  A 
APa/w1,2,&4 
•Vendors 
APs/w1,4&5 

•  Vendor  D 

APs/wl 

•  Vendor  L 

AP  sM  1 

•  VerKlor  M 

APs/wl  &2 

•  VefKlor  A 

Typel 
-  Vendor  F 

Typel 

ILS 

•  Vertdor  B. 

Typel 

•  Vendor  0, 

Type  1 

•  Vendor  A 

AP  sAw2 

•  Vendor  C 

APs/wl 

•  Vendor  E 

AP  aM  1 

•  Vendor  G 

APsAwl  &2 

•  Vendor  N 

AP  aAv  1 

-Vendor  0 

AP  sAw  1 

-  Verxlor  A 

Typel 

-  Vendors 

Type  1 

•  VerKlor  D 

Typel 

Service  Center 

•  Vendor  B, 

Typel 

•  Vendor  A 

Type  1 

-  Vendor  E 

Type  1 

Type  2 

-  Vendor  F 

Type  1 

-  Vendor  F 

APsA«2 

-  Vendor  T 

AP  s/w  1 

•  Vendor  U 

AP  s/w  1 

•  Vendor  V 

APsAwl  &2 

-  Vendor  W 

AP  s/w  1 

-  Vendor  X 

AP  sAw  1 

-  Vendor  G 

Type  1  &  2 

-  Vendor  H 

Type  1 
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TABLE  5-1.  XXX  Program  User  Capabilities  (coni) 


FUNCTION 

Program  Office, 
Engineering 


ILS 


Service  Center 
(DCC) 


Engineering 


ILS 


1  HARDWARE 

SOFTWARE 

1  NETWORKS 

-  Vendor  A. 

Type  1 

-  Vendor  B, 

Type  1 

-  Vendor  A 

AP  sAw  1 ,3,  &6 

•  VerKlor  B 

AP  sAv  1  &  4 

•  Vendor  C 

AP  s/w  1 

-  Vendor  E 

AP  s/w  1 

•  Vendor  G 

AP  s/w  1 

-  Vendor  N 

AP  s/w  1 

-  Vendor  P 

AP  s/w  1 

-  Vendor  A 

Type  1 

-  Vendor  B, 

Typel 

-  Vender  C, 

Type  1 

-  Vendor  E, 

Type  1 

-  Ve^or  H, 

Type  1 

-  Vendor  1, 

Type  1 

-  Vendor  J, 

Type  1 

•  Vendor  B. 

Type  1 
-  Vendor  E, 

Type  1 

•  Vendor  C 

AP  s/w  1  &  7 
Vendor  E 

APs/wl  &2 

•  Vendor  F 

APs/w2 

•  Vendor  G 

APs/wl 

-  Vendor  W 

AP  s/w  1 

-  Vendor  Y 

APs/wl 

-  VerKjor  C 

Type  1 

-  Vendor  A, 

Type  1 

-  Vendor  B, 

Type  1 

-  Vendor  C, 

Type  1 

-  Vendor  E 

Type  1 

-  Vendor  G 

Type  1 

-  Vendor  F 

AP  s/w2 

-  Vendor  A 

AP  s/w  1 

-  Vendor  E 

AP  s/w  1 

-  Vendor  G 

AP  s/w  1 

-  Vendor  J 

AP  s/w  1 

•  Vendor  B 

Type  1 

-  Vendor  1 

Type  1 

-  Vendor  J 

Type  1 

-  Vendor  A 

Type  1 

-  Vendor  B, 

Type  1 

-  Vendor  C, 

Type  1 

-Any  Commercial 
Software 

-  Vendor  B 

Type  1 

-  Vendor  D 

Type  1 

-  Vendor  B, 

Type  1 

-  Vendu  A, 

Type  1,2,3  &6 

-  Vendor  B, 

Type  1 

-  Vendor  B 

Type  1 

-  Vendor  D 

Type  1 

TABLE  5-1.  XXX  Program  User  Capabilities  (coni) 


USER 

FUNCTION 

HARDWARE 

SOFTWARE 

NETWORKS 

T4E 

-  Vendor  B, 

Typel 

-  Verxior  0, 

Typel 

-  Vendor  A 

APa^v1 

•  Vendor  C 

AP  sAv  1 

-  Vendor  E 

APa/wl  &2 

-  Vendor  G 

AP  sAv  1 

-  Vendor  L 

AP  sAv  1 

•  Verxlor  D 

Typel 

Engineering 

Support 

(Avionics  and 
Software) 

•  Vendor  B, 

Typel 

•  Vendor  C, 

Typel 

-  VeridorE, 

Typel  &  2 

-  Ve^or  H. 

Typel 

•  Vendor  1 

AP  sAw  1 

•Vendor  J 

AP  sAv  1 

•  Vendor  K 

APsAvl  &2 

•  Vendor  L 

AP  aAv  1 

-Vendors 

APsAvl 

-  Verxlor  B, 

Typel 

-  Verxlrx  C, 

Typel 

-  Verxlor  G, 

Typel 

ILS 

•  Vendor  B. 

Typel 

•  Vendor  A 

APsAvl  ,2.4&5 

•  Verxior  E 

APsAvl  &2 

•  Vendor  G 

AP  sAv  1 

-  Verxlor  Z 

AP  a/w  1 

Technical 

Pubiicettions 

-  Verxlor  B, 

Typel  &2 
•  Vendor  E, 

Typel 

-  Vendor  V 

APs/w  1 

-  Vendor  U 

AP  sAv  1 

•  Verxlor  G 

Type  1 
-  Verxlor  J 

Type  1 
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TABLE  5-1.  XXX  Program  User  Capabilities  (coni) 


USER 

FUNCTION 

HARDWARE 

SOFTWARE 

NETWORKS 

R&M 

-  Vendor  B, 

Type  1  &  2 
•  Vendor  H, 

Typel 

-  Vendor  G 

AP  s/w  1 
•  Vendor  X 

APs/wl 

-  Vendor  1 

Type  1 

m 

ILS 

-  Vendor  A 

Type  1 

-  Vendor  B. 

Type  1  &  2 

-  Vendor  C. 

Type  1  &  3 
•  Vendor  0. 

Type  1  &  2 

-  Vendor  E. 

Type  3 

-  Vendor  A 
APs^v1,2.5&6 

-  Vendor  E 

APs/wl  &2 

-  Vendor  G 

APs/wl  42 

-  Vendor  R 

AP  s/w  1 

•  Vendor  X 

AP  s/w  1 

-  Vendor  A 

Type  1 

IHHHHHHH 

Depot  Planning 

•  Vendor  B, 

Typel 

•  Vendor  A 

APs/w6 

•  Vendor  C 

AP  s/w  1 

•  Vendor  E 

AP  s/w  1 

-  Vendor  B 

Type  1 
•  Vendor  G 

Type  1 

Supply  Support 

•  Vendor  B, 

Typel 

-  Vendor  A 

AP  s/w  6 

•  Vendor  C 

AP  s/w  1 

-  Vendor  E 

APs/wl  42 

-  Verrdor  G 

AP  s/w  1 

-  Vendor  W 

AP  s/w  1 

-  Vendor  K 

Type  1 

■  Vendor  L 

Type  1 

-  Vendor  M 

Type  1 

Require".-.  iL 

-  Vendor  B. 

Type  1 

-  Vendor  A 

APs/w6 

-  Vendor  C 

AP  s/w  1 

-  Vendor  E 

AP  s/w  1  4  2 

-  Vendor  G 

AP  s/w  1 

-  Vendor  B 

Type  1 

Supply  Support 

mmmmmi 

— 
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TABLE  5-1 .  XXX  Program  User  Capabilities  (coni) 


FUNCTION 

HARDWARE 

SOFTWARE 

NETWORKS 

PHSAT 

-  Vendor  B 

Typel 

-  Vendor  D 

Typed  &4 

•  Vendor  A 
APsNv5&6 

-  Vendor  C, 
APs^v1  &2 

-  Vendor  E 

APa/w2 

-  Vendor  G 

APsMI  &2 

-  VertdorM 

APs/wl 

-  Vendor  R 

AP  s/w  1 

-Vendors 
Type  1 
-  Vendor  1 

Type  1 

Engineering 
Support  C^ehicle 
Dynamics) 

-VerxlorA 

Type  2 
-  VeiKior  B, 

Typel 
•  Vendor  C, 

Type  3 

-Vendor  A 

AP  a/w  2.  3  &7 

-  Vendor B 
APs/w2.4&5 

-  Vendor  E 

APsNvl  &2 

-  Vendor  R 

AP  a/w  1 

•  Vendor  X 

AP  s/w  1 

-VefKiorB 
Typel 
-  Vervlor  0 
Typel 

5^  Infrastructure  Modernization  Programs  (IMP) 

The  DoD  is  building  various  CALS-supporting  systems  for  generation,  receipt,  storage, 
distribution,  and  processing  of  digital  data  These  systems,  briefly  described  below,  will 
be  used  to  various  extents  in  XXX  programs  depending  on  the  programs'  data 
requirements,  existing  capability,  and  IMP  availability.  Additional  detail  regarding  exact 
systems  to  be  used  and  their  capabilities  will  be  provided  as  they  become  available. 

•  Digital  Document  Management  and  PublisNng  Systems  allow  for  the 
acceptance,  validation,  maintenance,  and  publishing  of  SGML-encoded 
technical  manual  data  These  systems  will  provide  for  the  continued  use  and 
maintenance  of  digitized  technical  documentation  throughout  the  life  cycle  of  a 
defense  system. 

•  Digital  Technical  Information  Systems  are  typically  capably  designed  to  place 

current  and  accurate  digital  technical  data  into  users'  hands  and  allow  engineers 
to  access  technical  documentation,  retrieve  it  from  a  digital  repository,  and 
create  technical  information  files  containing  repair/planning  data. 

Documentation  to  be  available  includes  engineering  drawing,  technical  manuals, 
preventive  maintenance  data,  and  engineering  operating  and  sequencing  data 

•  Joint  Engineering  Data  Management  Information  and  Control  Systems 
(JEDMICS)  provide  a  standard  digital  system  for  storage,  retrieval,  reproduction, 
and  distribution  of  engineering  drawings  and  related  technical  data  to  support 
weapon  system  maintenance,  reprocurement  of  spares,  engineering,  training, 
manufacturing,  and  logistics  support. 

•  Solicitation  Package  Automation  (SPA)  stores  CALS-compliant  digital 
solicitation  packages  (forms,  clauses,  technical  specifications,  and  drawings)  for 
print-on-demand  output  at  the  two  inventory  control  points. 

•  Interactive  Electronic  Technical  Manual  (lETM)  is  a  computer-based  collection  of 
information  that  can  be  used  for  the  diagnosis  and  maintenance  of  a  defense 
system,  optically  arranged  and  formatted  for  interactive  presentation  to  an  end 
user  on  an  electronic  display  system.  lETM  is  an  irrteractive  display  system 
using  optimally  packaged  and  formatted  technical  information  for  screen 
presentation  of  maintenance  and  diagnostics  information. 

•  Joint  CALS  (JCALS)  is  a  DoD  initiative  to  address  a  global,  integrated  database 
serving  edi  database  system  users;  connectively  of  all  users  by  local  and  wide 
area  networking;  implementation  and  incorporation  of  existing  and  evolving 
digital  data  standards;  provision  of  a  trusted  computing  environment 
implementing  B1  level  security;  and  an  open  systems  environment  to  provide 
flexibility  and  to  protect  against  premature  obsolescence.  The  primary  goal  of 
the  current  JCALS  design  is  the  integration  of  databases  into  a  shared 
structure,  an  Integrated  Weapons  Systems  Data  Base  (IWSDB),  while  creating 
an  environment  where  logistic  technical  information  could  be  processed 
efficiently. 
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6.0  XXX  PROGRAM  CALS  IMPLEMENTATION 


For  the  XXX  programs,  the  Government  plans  on  establishing  a  distributed  information 
network  system.  Figure  6.1  depicts  a  representative  functional  arrangement  of  the 
XXX  program  network  that  will  be  implemented  during  engineering  and  manufacturing 
developrnem  and  used  throughout  the  life  cycle  of  the  XXX  program. 


XXX  PROGRAM  CALS  SUPPORT  SYSTEM 


DOD  ACTIVITY 


IT  ANALTI 


c 


ACQUIS  IT  ION 


MANAS! R 


ILS  TtAININS 


/  /  /'''"^s  HAZARD  “N.  N. 

/  /  ^  ANALYSIS  J  _ _ _ 

_ .^^^"oss u ppoTr^ \  \ 

_  _  (  CONT  R  ACT  OR  (Sl^ 

1  \  ^CONPISUR  ATION 

QUALITY  ^  /  / 

N.  V^ASSURANCi^/  I  / 

ICHNICAl 


DATA 


CONT  AINU 
DIIISN  AS!  NT 


000  SUPPORT 
ACT  IVIT  T 


FA  ANAITS 


DOD  SUPPORT 
ACT  IVIT  T 


DOD  SUPPORT 

'r  "  ~~?l 

j 

DOD  SUPPORT 

AaiVITY 

1^-  ■  — 

ACT  IVIT  Y 

FIGURE  6.1.  CALS  Functional  Arrangement 

As  is  illustrated,  this  network  ties  all  XXX  program  activities  together  by  a  Wide  Area 
Network  (WAN).  This  WAN  will  be  implemented  under  a  Computer  and 
Telecommunications  Command  Network.  Authorized  users  will  have  access  directly  or 
through  dial-up  modems  as  dictated  by  data  volume,  current  and  planned 
telecommunications,  and  program  requirements.  The  function  of  the  XXX  program 
WAN  is  to  provide  electronic  communications  among  all  XXX  program  activities, 
thereby  allowing  electronic: 
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•  Communications  among  all  activities  via  electronic  mail  (E-Mail) 

•  Transfer  of  deliverable  data  files  from  the  contractor  to  the  XXX  CALS  sen/ice 
center  or  directly  to  users  as  specified  on  DO  Form  1423s 

•  T ransfer  of  contractor-deliverable  data  files  from  the  service  center  to  users 

•  T ransfer  of  program  data  files  among  Navy  users 

•  T ransfer  of  GFI  directly  to  corrtractors 

•  Access  to  CITIS  by  all  authorized  users. 

Contract  delivery  of  magnetic  or  on-line  transfer  data  will  be  to  the  XXX  program 
service  center.  The  service  center  will  perform  data  management  and  perform  as  the 
repository  for  all  XXX  program  contract  deliverables.  Specific  functions  to  be 
performed  are  to  be  determined. 
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SAMPLE  STATEMENT  OF  WORK  LANGUAGE 


General 

This  Generic  Statement  of  Work  (SOW)  provides  sample  language  to  assist  in  the 
implementation  of  Computer-Aided  Acquisition  and  Logistics  Support  (CALS)  for  an  acquisition 
program.  content  within  each  sample  paragraph  should  be  tailored  for  each  application. 
This  CALS-related  language  should  be  used  in  de'^loping  the  functiortal  requirements  within 
each  applicable  section  of  the  Request  For  Proposal  (RF^  SOW.  This  language  is  not  intended 
to  be  inserted  as  a  stand-alone  section  within  the  RFP  SOW. 

SOW  Para.  1.0  Scope 

The  contractor  shall  establish  a  digital  technical  information  (Tl)  system  to  provide  automation 
and  integration  of  the  generation,  delivery,  and  uses  of  fprooram  name!  technical  information 
over  the  ^defense  system*  or  *eouiDment*l  life  cyde.  Unless  othenwise  specffied  within  the 
contract,  all,  or  any  portion  of,  the  technical  information  (Tl)  specified  herein  shaB  be  developed  in 
a  digital  form  comp^ible  with  requirements  stated  herein.  Unless  specifically  stated  herein,  the 
following  requirements  do  not  replace  or  amend  requirements  for  defivery  of  Tl  in  non-digital 
forms  specified  in  elsewhere  in  the  contract 

SOW  Para.  2.0  SoecKic  Reouirements 

The  contractor  shall  implement  a  CALS  program  that  wiO  achieve  the  following  ot^ectives; 

a.  Integrate  corttractor  technical  information  systems  and  processes; 

b.  Authorize  Government  access  to  the  contractor  data  base(s);  and; 

c.  Deliver  technical  information  in  digital  forms  using  the  MIL-STD-1840  and  accompanying 
specifications  for  data  interchange  (MIL-28000  series). 

SOW  Para.  2.1  CALS  Implementation  Plan  fCALSIP)  [OPTIONAL  for  Section  C  SOW;  preferred 
use  is  Section  L  for  delivery  as  a  proposal  requirement  for  evaluation  during  source  selection.  If 
deemed  necessary  as  a  CDRL  delivery  requiremert,  recommend  include  in  a  section  of  an 
existing  Martagement  Plan  (Program,  System  Engineering  or  ILS)  deliverable  rather  than  as  a 
separate  document.] 

The  contractor  shall  develop  and  maintain  a  currem,  comprehensive  and  detailed  CALS 
Implementation  Plan  (CALSIP)  outlining  the  procedures  to  be  used  to  accomplish  the  CALS 
requirements  defined  in  fSection  X.X1  of  this  statement  of  work  (SOW).  The  CALSIP  shall 
address  capabilities  for  automating  the  access  and  retrieval  of  CAE/CAD^IM/logistics  technical 
data,  and  provide  for  digital  exchange  and  integration  between  the  engineering,  manufacturing, 
logistics  and  other  functional  areas  as  appropriate  to  this  acquisition  phase  of  the  program. 

The  CALSIP  shall  address,  as  a  minimum,  the  following: 

a.  CALS  objectives,  strategy  and  management  approach,  including  application  of 
Concurrent  Engineering 

b.  Database  architecture,  covering  operational  requirements  and  system  tradeoffs 

c.  Digital  data  validation  and  verification  and  conformance  to  standards  for  delivery 

d.  Telecommunications,  data  rights/access  and  systerryphysical  security 
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sow  Para.  2.1.1  CALS  Approach 


The  contractor  shall  define  a  specific  CALS  implementation  obfective  and  strategy,  taking  into 
consideration  technical  constraints,  quality  and  cost  guidelines  and  the  Govemmerfi  Conc^  of 
Operations  (GCO}  established  by  the  service  Acquisition  Manager.  This  strategy  shafl  be 
supported  by  necessary  trade  studies,  and  shall  describe  the  framework  for  CALS 
implementation  activities  to  be  accomplished  during  each  phase  of  fprooram  namel  system 
dev^pmenL  The  strategy  shall  define  how  the  principles  of  concurrent  engineering  be 
applied,  identify  the  critical  enablers  for  CE  fi-e..  integrated  data  base),  and  provide  details  on 
how  program  risk  and  costs  will  be  reduced  and  product  quality  improved  through  CE  initiatives. 
The  implementation  strategy  shall  serve  as  a  guide  in  developing  contractual  requirements  for 
later  program  acquisition  phases.  [The  followirtg  additional  language  should  be  used  in  Section  C 
SOW  if  CDRL  deiiverabie  is  desired.]  The  CMSIP  will  be  updated  fdavri  prior  to  the  end  of  this 
contract  phase  and  shall  define  implementation  plans  for  the  upcoming  phase  in  greater  detail, 
resolve  outstanding  strategy  issues,  respond  to  strategic  and  technology  changes,  and 
recommend  specific  alternative  approaches  for  continuation  of  CALS  in  the  next  phase. 

SOW  Para.  2.1.2  Database  Architecture/Svstem  Tradeoffs 

The  contractor  plan  shall  propose  pprovide*  if  Section  C  SOW  and  CALSIP  is  CORL  deliverable] 
a  cost  effective  method  of  managing  the  utilization  of  the  contractor  set  of  automated  data 
processing  systems  and  applications  which  support  specific  weapon  system  technical  data 
base(s)  such  that  appropriate  configuration  and  version  control  of  techrucal  information  is 
maintained,  while  providing  cunent  data  for  design,  engineering  arialysis,  manufacturing,  and 
product  support  planning.  [The  following  additional  language  should  be  used  in  Section  C  SOW  K 
CDRL  deliverable  is  desired.]  The  contractor  shall  conduct  appropriate  tradeoffs  studies/ 
analyses  to  support  determination  of  the  CALS  implementation  strategy.  The  status  of  these 
studies  shall  be  reviewed  at  appropriate  program  management,  design,  and  ILS  reviews,  and  the 
results  documented  as  part  of  the  CALSIP.  Candidates  for  such  studies  include; 

[Examples  only;  final  determination  is  program  specific] 

•  improved  alternate  data  generation  and  delivery  modes 

•  digital  data  delivery  vs.  orvline  access 

•  identification  and  elimination  of  unnecessary  CDRL  items 

•  identification  of  CDRL  items  for  interactive,  on-line  review 

•  analysis  of  telecommunication  alternatives 

•  functional  integration  cost/benefit  studies 

•  cost  effectiveness  of  contractor  interim  CALS  support  [particulariy  in  areas  where 

infras'ncTti'  '  <>:  ability  limitations  can  be  overcome  through  use  of  hardware/sc^^vare 

'“rsci  from  the  contractor], 

SOW  Para.  2.1.3  CALS  Standards  Corrformance  Test 

The  contractor  shall  include  in  the  CALSIP  plans  to  demonstrate  the  exchange  of  digital 
deliverables  using  the  CALS  standard  formats,  in  accordance  with  the  full  requirements  of  MIL- 
STD-1840  and  all  tiers  of  references  (specifically  MIL-28000  series  format/interchange 
specifications).  This  shall  be  accomplished  through  testing  provided  by  the  Government  or  an 
industrial  organization(s)  chartered  to  perform  such  conformance  test.  [Tf^e  following  additional 
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language  should  be  used  in  Section  C  SOW  if  CORL  deliverable  is  desired.]  AddHiortally,  Tl 
deliverables  must  pass  a  first  article  test  on  ait  formats  to  ensure  conformance  to  the  CALS 
specifications. 


SOW  Para.  2.1 .4  Security  [Section  C  SOW  requirement  only] 


The  contractor  shall  establish  a  security  system  and  enforce  data  protection  and  integrity 
standards.  System  security  engineering  principles  as  outfined  in  MIL-&TD-178S  shall  be  used. 
Controls  to  prevertt  unauthorized  access  shatt  be  agtahifehAd  and  detailed  in  the  CALSIP.  The 
plan  shall  be  based  on  the  results  of  documented  data  protection  and  integrity,  threat  and 
vulnerability  analysis,  risk  assessments,  and  tradeoff  analyses.  VuinerabHities  that  remain  after 
security  sykem  design  shaO  be  identified.  The  plan  shall  include  disaster  recovery  provisions. 
Security  requirements  that  must  be  corryilied  with  by  Government  personnel  wfll  be  identified  to 
the  Government  in  the  security  section  of  the  CALSIP.  Any  peaiiar  software  that  must  be 
resident  on  Government  access  terminals  will  be  provided  and  maitaained  by  the  cortractor. 
Information  requirirtg  special  security  provisions  sur^  as  dassNied  data,  critical  technology  and 
proprietary,  competition  or  fiabiiity  sensitive  data  win  be  partitioned  to  minimize  the  volume  of 
information  requiring  spedaiized  handling,  to  provide  dassHication  at  the  lowest  classification 
level,  and  to  contrd  access.  Encryption  of  classified  data  or  sensitive  military  data  shall  be 
stipulated  by  the  CDRL  and  on  an  as-re<^ed  basis  in  accordance  with  procedures  established 
by  the  National  Security  Agency.  Such  information  shaO  be  identified  to  prevent  inadvertent 
disclosure  and  retention  of  security  iderttification  for  printouts  of  accessed  infomuriion.  The 
contractor  shall  pay  particuiar  attention  to  undassIM  items  of  information,  which,  taken 
together,  can  infer  classified  infomtatiorL  The  contractor  shall  maintain  configuration  contrd  of 
the  security  system  and  trusted  system  corrtponents.  The  contractor  shaU  condud  a  test  and 
evaluation  of  the  system  and  periodic  irtspedions  to  ensure  compliartce.  The  Government  shall 
retain  the  right  to  condud  announced  and  unannounced  inspections  by  security  speciaiists  at  any 
time  to  review,  audiL  and  account  for  dassified  materials. 


SOW  Para.  2.2  Program  Assessment  and  Contrd  -  DoD  Reviews 


The  CALSIP  shafl  describe  the  procedures  and  controls  by  which  the  contrador  and  the 
Government  will  evaluate  the  status  and  effediveness  of  CALS.  The  implementation  of  the 
CALS  will  be  a  subjed  of  review  at  program,  design  and  ILS  reviews. 


SOW  Para.  2.3  Post  Award  CALS  Program  Orientation  Conference  [Sedion  C  SOW  language 
only] 


The  prime  contrador  shall  host  a  post  award  CALS  program  orientation  conference  to  be 
scheduled  no  later  than  fnumberl  of  days  after  contrad  award.  A  representative  from  the 
forooram  namel  program  office  shaH  chair  this  corrference.  Major  prime  corrtrador  teaming 
partners/subcontradors  shall  attend.  The  agenda  for  this  conference  shall  be  approved  by  the 
forooram  namel  program  office.  The  purpose  of  this  CALS  meeting  is  to  clarify  the  GCO  and 
have  the  contractor  present  to  the  Government  their  plans  for  on-line  access  if  required, 
exchange  and  delivery  of  digitai  data. 


SOW  Para.  2.4  Government  Furnished  Informatkm  fGFR 


The  contrador  CALSIP  shall  describe  the  GFI  the  contrador  expects  to  receive  from  the 
Government  The  list  of  GFI  the  Government  plans  to  provide  is  included  in  attachment/exhibit 
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fnumberl.  This  list  should  include  those  elements  to  be  addressed  in  the  GCO.  The  GCO  will 
define  infrastructure  capabilities  to  receive  and  use  various  types  of  digital  data  and  technical 
information.  The  contractor  shall  use  this  GFI  with  contractor  generated  data. 

SOW  Para.  3.0  Contractor  Integrated  Technical  Information  Services  fCmSi 

The  contractor  shall  propose  pdevelop*  if  Se^ion  C  SOW  reqiwement]  a  program  composed  of 
procedures,  processes,  spedfications  and  software  applications  for  the  integration,  storage, 
exchange,  and/or  on-line  sharing  of  data  with  the  Government.  These  technics  data  and  data 
base(s}  and  functional  application  capabilities  provided  within  the  contractor's  system  shall  be 
referred  to  as  the  CITIS.  This  CITIS  shall  he  developed  usirtg  the  Cms  Functional  Specification, 
Attachment  ( ),  and  the  following. 

The  contractor  shall  propose  ^develop*  for  Section  C  SOW  requirement]  a  technical  information 
(Tl)  aixi  program  management  architecture,  with  a  functiorrai  and  hierarchical  irrdexir^  system  to: 

*  Manage  configuration  of  the  entire  Tl  and  planning  data  bases, 

*  Integrate  planning  information  into  its  respective  Tl  source  data  base;  and 

*  Trace  corifiguration  changes  from  design  to  logistics  products  and  vice  versa. 

The  contractor  shall  propose  how  he  will  pis  required  to*  for  Section  C  SOW  language]  establish 
a  link  among  logistics,  design,  engineering,  and  manufacturing  data  and  functional  processes  to 
facilitate  the  interchange  and  exchange  of  technical  information;  integrate  technical  data  and  data 
base(s)  to  support  the  design,  manufacturing  and  support  processes  and  allow  for  timely  access 
by  authorized  Government  activities;  provide  an  integrated,  shared  data  environment,  consisting 
of  integrated  data  bases,  analysis  tools,  artd  engineering  processes  designed  to  utilize  digital  Tl; 
and,  provide  for  the  generation,  storage,  indexing,  distribution,  and  delivery  of  integrated 
acquisitibn  and  logistics  information  products.  In  the  selection  of  artalytical  tools,  the  contractor 
shall  maximize  the  use  of  previously  developed  or  off-the-shelf  software.  These  software  tools 
shall  be  compatible  with  hardware/software  system  specified  in  the  GCO,  unless  contractor 
developed,  unique  software  solutions  are  demonstrated  to  be  more  cost  effective. 

The  contractor's  telecommunications  solution  for  CITIS  shall  comply  with  Government  Open 
System  Interconnect  Protocols  (GOSIP).  The  U.S.  GOSIP  specified  protocols  are  required  as 
contained  in  FIPS  146.  GOSIP  includes  selected  Open  Systems  Interconnection  (OSI),  Institute 
of  Electrical  and  Electronics  Engineers  (lEE^  and  International  Consultative  Committee  for 
Telephone  and  Telegraph  (CCITT)  specified  protocols. 

SOW  Para.  3.1  Data  Element  Dictionary  [Section  C  SOW  only] 

A  general  data  element  dictionary  shall  be  developed  so  that  identical  data  elements  are 
addressable  by  the  computer  as  the  same  data  element.  Changes  to  any  duplicate  data  element 
shall  be  effected  throughout  all  data  bases.  A  similar  methodology  shall  be  developed  for 
graphics  and  large  textual  entities  to  ensure  that  changes  to  the  source  graphic  correctly  flags  the 
necessity  for  change  to  all  dependent  graphicAextual  entities  derived  from  the  source  graphic. 
The  contractor  shall  use  existing  MIL-STD  data  dictionaries,  to  include  MiL-STD-1 388-2,  and  use 
MIL-HDBK-59  as  guidance  in  constructing  the  loroorami  data  dictionary. 
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sow  Para.  4.0  Enoineerino  Data  faranhic  and  text  files!  [Section  C  SOW  only] 

Any  data,  either  Government,  contractor,  or  veridor,  that  contains  engineering  definition  or 
guidance  on  material  items  (components),  equipment  system  practices,  methods,  and/or 
processes  relating  to  the  design,  rrtanufacture,  acquisition,  test,  inspection  shall  be  submitted  in 
digital  form  in  accordance  with  MIL-STD-1840A  and  compatible  with  the  data  repository/receiving 
systems  specified  in  the  GCO. 

[The  following  paragraphs  contain  language  that  should  be  Integrated  with  the  specific  functional 
area  that  It  addresses.] 

SOW  Para.  5.0  Automation  &  Functiortal  Integration 

The  contractor  should  use  computer-aided  design,  engirteering,  artd  manufacturing  methods 
(CAD/CAE/CAM)  to  support  design  integration  with  manufacturing  planning  and  logistic  support 
system  development  These  software  tools  shall  be  compatible  with  hardware/software  systems 
specified  in  the  GCO,  unless  contractor  developed,  unique  softwey-e  solutions  with  are 
demonstrated  to  be  more  cost  effective.  An  integrate  set  of  AOP  systems  and  applications  will 
be  used  by  the  contractor  team  to  enter,  update,  martage,  and  retrieve  data  from  specific 
(program)  technical  data  base(s). 

SOW  Para.  5.1  R&M  Automation 

The  contractor  shall  employ  automated  tools  for  performing  R&M  tasks.  The  contractor  shall 
integrate  these  R&M  tools  with  other  CAE  tools.  These  tools  may  stand  alone  with  no  direct 
access  to  the  CAE  data  base;  reside  in  the  CAE  system  arnl  interfaced  with  the  evolving  design; 
or,  reside  on  the  CAE  system  and  be  automatically  invoked  to  support  design  decisions.  The 
R&M  methods  and  tools  used  by  the  contractor  shall,  as  a  minimum,  include; 

*  Automated  R&M  analysis  procedures  coupled  to  parts  libraries  and  to  material 
characteristics  data  bases. 

*  Automated  R&M  synthesis  based  on  design  rules  and  lessons  learned  from  prior  design 
experience  and  field  use. 

*  Fully  characterized  (tested  and  validated)  component  performance  and  R&M 
characteristics  data  bases. 

*  Design  decision  traceability. 

SOW  Para.  5.2  R&M-LSAR  Integration 

The  contractor  shall  establish  an  automated  link  to  satisfy  LSAR  documentation  requirements  for 
initial  and  updated  reliability  and  maintainability  (R&M)  information.  Algorithms  or  transformations 
that  must  be  applied  to  R&M  source  data  elements  to  conform  to  LSAR  documentation 
requirements  shidi  be  documented.  TraceabUity  between  the  LSAR  and  individual  R&M  data 
sources,  and  the  preservation  of  appropriate  data  flows  while  maintaining  established  LSAR  data 
element  relationships  and  interdependencies,  shall  be  clearly  demonstrated. 

SOW  Para.  5.3  LSAR  Data  Automation 

The  contractor  shall  establish  and  maintain  a  validated  LSAR  automated  data  processing  system 
capable  of  input,  storage,  and  retrieval  of  LSAR  data  in  accordance  with  MIL-STD-1 388-2.  The 


5 


contractor  may  use  an  internally  developed  and  Government  validated  LSAR  automated  data 
processing  system,  or  independently  developed  arKi  Government  validated  LSAR  automtted 
data  processing  system.  The  contractor  shall  partition  LSAR  working  data  for  in-process  reviews 
and  maintain  these  files  separate  from  Government  approved  LSAR  data.  The  LSAR  version 
containing  the  submitted  data  shall  be  the  LSAR  that  has  been  subiected  to  internal  contractor 
review  procedures  and  is  pending  Government  review  and  approval.  The  LSAR  working  data 
shall  be  updcited  in  accordance  with  the  schedule  in  the  LSA  plan  regardless  of  the  approval 
status  of  ttw  working  data's  content  since  the  last  update.  Upon  Government  approval,  LSAR 
working  data  shall  be  transferred  to  the  Government  approved  LSAR.  All  Government  directed 
changes  resulting  from  the  LSAR  data  shall  be  cumulative  of  all  Government  approved  LSAR 
data.  Delivery  of  LSAR  data  shall  be  lAW  the  CDF^ 

SOW  Para.  5  4  Reliabllitv  Centered  Maintenance  fRCM)  and  Aoe  Exploration  Automation 

The  contractor  shall  develop  an  automated  system  to  maintain  a  complete  ROM  audit  trail 
throughout  the  forooram  name!  life  cycle.  This  audit  trail  will  permit  traceabBIty  of  preventive 
maintenance  tasks  back  to  specific  engirMerirrg  failure  rruxies  listed  in  the  LSAR.  The  automated 
ROM  analysis  process  must  hnve  the  cap^xiity  of  deliverirrg  results  digitally  arxl  through  an 
interactive  electronic  interface  with  the  LSAR  data  base.  The  contractor  shall  utilize  the  ROM 
automated  worksheet  process  or  a  contractor  developed,  DoD  vafidated,  ROM  automated 
process  with  the  capability  of  automatically  transferring  compatible  data  to  the  Government  ROM 
software.  The  automated  ROM  analysis  data/work-sheets  must  be  delivered  to  the  Government 
in  accordance  with  the  CORL 

The  contractor  will  develop  an  Age  Exploration  (AE)  data  base  for  the  storage  and  analysis  of  in¬ 
service/operational  age-reliability  data  which  shall  be  used  to  support  the  ROM  analysis  process. 
The  AE  data  base  shall  be  integrated  digitally  and  have  an  interactive  electronic  interface  with  the 
ROM  automated  process. 

SOW  Para.  5.5  Level  of  Repair  Analysis  fLORAI 

The  contractor  shall  employ  an  automated  system  to  perform  LORA  in  accordance  with  the 
requirements  specified  MIL-STD-1390.  The  contractor  shall  establish  a  data  base  as  a  repository 
for  LORA  input  data  and  LORA  output  report  files  generated  by  execution  of  the  LORA  model 
software.  The  LORA  data  base  will  be  integrated  with  the  automated  LSAR  data  base  to 
maintain  traceability  of  LSA  data  used  as  input  to  the  LORA.  The  output  results  of  the  LORA 
shall  be  documented  in  the  LSAR  for  development  of  the  LSA-024  maintenance  plan  report. 
Approved  LORA  input  data  files  and  output  reports  shall  be  delivered  in  accordance  with  CDRL 
specified  delivery  mode  (i.e.,  deliverable  digital  media  or  on-line  access/retrieval). 

SOW  Para.  6.0  Diagnostics 

The  source  of  diagnostic  information  will  reside  in  logistics  engineering  data  bases  offering  data 
exchange  in  neutral  formats.  Software  shall  be  developed  to  provide  for  automated  interface  with 
in-service  performance  and  maintenance  data  collection  processes  and  to  provide  feedback 
concerning  successes  and  failures  in  the  fault  isolation  process  to  the  [program]  system  designer. 
Diagnostic  systems  that  learn  from  experience  and  which  have  the  capability  to  update  a 
knovriedge-based  diagnostic  data  base  to  optimize  the  fault  isolation  process  or  to  improve 
system  design  are  to  be  used  to  the  fullest  extent  possible. 
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The  conb'actor  shall  f^tabiish  an  on-line  direct  access  capability  for  recording,  planning, 
scheduling,  and  referring  status  of  program  requirements.  This  shaB  provide  visibility  of  the 
contractor's  per.'^.mance,  highlight  potenbaJ  problems,  arxf  provide  schedule  compatibilfty  checks 
to  ensure  integration  of  functiortal  activities.  This  orvline  capability  shall  identify  change  impacts 
on  related  areas  of  logistic  support,  design  and  martufacturing,  and  provide  the  status  of  program 
deliverables. 


SOW  Para.  6.0  Technical  Manuals 

The  contractor  shall  provide  for  computer  assisted  generation  of  technical  rrumuala^orders.  This 
data  is  to  be  derived,  to  the  maximum  extent  possible,  from  integrated  digital  data  files,  e.g., 
CAO/Engirreering  Data  Base/LSAR.  This  data  shall  be  provided  in  accordance  fService- 
unigue  specifications  and  TM/TO  developmerB  guidance  or  other  TM/TO  SOW  reouirementsi . 

SOW  Para.  9.0  Supply  Support 


The  contractor  shafl  maintain  spare  parts  idMTtification  consistent  with  the  approved 
configuration  baseline  and  allow  for  orvline  assessment  of  the  impact  to  spare  parts  requirements 
during  analysis  of  design  alternatives.  The  contractor  shall  provide  provisioning  technical 
documentation  in  accordance  with  MIL-STD-1 388-2  to  facilitate  automated  ordering,  supply 
management,  and  distribution,  and  should  provide  orviine  identification  of  spares,  repair  parts, 
and  source/maintenance/recoverability  coding.  This  data  shall  be  provid^  LAW  lSer\^ee-in 
unique  specificatiorts  and  TM/TO  development  guidance  or  other  TM/TO  SOW  reouirennentt. 


SOW  Para.  10.0  Facilities  Data 


The  contractor  shall  provide  facilities  data  in  digftal  form  in  accordance  with  MIL-STD-1 840A 
consistent  with  data  derived  from  the  LSAR  data  base.  Engir>eering  drawings  and  specifications 
shall  be  provided  in  accordance  with  paragraphs  4.0. 


SOW  Para.  1 1 .0  T raining 


Training  data  should  be  developed  in  accordance  with  MIL-STD-1 388-2,  MIL-STD-1379  and  MIL- 
HDBK-292.  The  LSAR  data  base  shall  provide  source  data  to  MIL-STD-1379  program  software 
for  producing  output  reports  and  instructional  materials.  Authorized  system  software  shall  be  in 
accordance  with  GCO  specified  requirements. 
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FOREWORD 


Purp<»e 

The  Navy  Computer-aided  Acquisition  and  Logistic  Support  (CALS) 
Acquisition/Implementation  Sub-Group  has  charged  the  CALS  Resource 
Implementation  Cooperative  (RIQ  with  developing  acquisition  guidance  for  each  of  the 
three  process  architectures  defined  in  the  Navy  CALS  Acquisitiort/Impiementation  Ran. 
This  document  is  the  result  of  an  exhaustive  search  and  distillation  of  information 
pertinent  to  applying  CALS  to  the  creation,  management,  and  use  of  Technical  Data 
Packages  (TDPs).  The  ir^ended  audience  of  this  document  is  Navy/Marine  Corps 
Acquisition  Managers,  project  engineers,  and  project  logisticians.  This  document  lends 
itself  to  incorporation  into  specific  Naval  Forces  System  Command  and  Marine  Corps 
program  manager  guides  for  applying  CALS  to  defense  system  procurements. 

Scope 

The  three  process  architectures  described  in  the  Naval  Forces  CALS  Architecture  and 
Environment  are: 

•  Engineering  Drawings 

•  Technical  Manuals 

•  Logistic  Support  Analysis  Record  (LSAR). 

This  revision  has  been  expanded  to  include: 

•  Cost/Pricing  Matrix 

•  Proposal  Evaluation  Criteria 

•  Discussion  on  Contractor  Integrated  Technical  Information  Service  (CITIS) 

•  Decision  Oriented  Templates. 

Overview 

Section  3.0,  General  Considerations,  provides  topics  of  consideration  that  must  be 
addressed  by  the  Acquisition  Manager  pertaining  to  the  application  of  the  CALS 
strategy  to  technical  data  packages.  This  section  covers  the  following  considerations: 

•  TDP  Bements 

•  TDP  Decision  and  Responsibility 

•  Identifying/Establishing  a  TDP  Requirement 

•  TDPs  in  the  CALS  Environment 

•  CALS  Requirement  Documents 

•  Navy  Infrastructure  Development 

•  Data  Uses. 

Section  4.0,  Specific  Considerations,  uses  these  topics  as  a  basis  to  address  additional 
requirements  when  acquiring  TDPs  in  a  CALS  environment  such  as  selection  of  data 
formats  and  delivery  media  and  cost  considerations.  Sample  contract  language  is  also 
provided. 


1 


(This  page  intentionally  left  blank.) 


TABLE  OF  CONTENTS 


1.0  INTRODUCTION .  1 

1.1  Scope .  1 

1.2  Purpose .  1 

2.0  REFERENCES .  3 

2.1  Acronyms .  3 

2.2  Definitions .  4 

2.3  Applicable  Documents .  4 

3.0  GENERAL  CONSIDERATIONS .  5 

3.1  Technical  Data  Package  (TDP)  Bements .  5 

3.1.1  Drawings  and  Associated  Lists .  5 

3.1.2  Illustrated  Text  Documentation .  6 

3.2  TDP  Dedsion  and  Responsibility .  6 

3.3  TDPs  in  the  CALS  Environment .  8 

3.3.1  NondigitaJ  Data  Deliverables  (Originals  and  Reproducibles) .  8 

3.3. 1.1  Paper,  Mylar  Hardcopy .  8 

3.3. 1.2  Aperture  Cards .  9 

3.3.2  Digital  Data  Deliverables .  9 

3.4  Life  Cycle  Considerations .  10 

3.4. 1  Contract  Data  Requirements  List  (CDRL) .  1 0 

3.5  CALS  Requirements .  12 

3.6  Infrastructure  Development .  12 

3.7  Data  Uses .  13 

4.0  SPECIFIC  CONSIDERATIONS .  15 

4.1  TDP  Delivery .  15 

4.1.1  Potential  TDP  Delivery  Options .  15 

4.1. 1.1  Raster .  15 

4. 1 . 1 .2  Processable  Data  Res .  1 6 

4. 1 . 1 .1  Drawing  and  Product  Data  Res .  16 

4.1.1 .2.2  Illustrated  Text  Data  Files .  1 7 

4.2  Existing  TDP  Availability .  18 

4.3  TDP  Format  Determination .  19 

4.4  TDP  Development  Decision .  20 

4.4.1  Government  Maintenance  and  Control  of  the  TDP .  23 

4.4.2  Competitive  Reprocurement .  23 

4.4.3  TDP  Modification/Revision  Determination .  23 

4.4.4  Digital  System/Environment .  23 

4.4.5  Digital  System/Environment  Compatibility .  24 

4.4.6  TDP  Data  Requirements  (Compatible  Systems) .  24 

4.4.7  TDP  Data  Requirements  (Incompatible  Systems) .  24 

4.4.8  Raster  Delivery  Option .  25 

4.4.8. 1  Cost .  25 

4.4.8.2  CDRLs .  25 

4.4.9  Product  Data  File  Delivery  Option .  25 

4.4.9. 1  Cost .  35 

4.4.9  2  CDRLs .  35 

iii 


4.4.10  Native  CAO/CAE  Data  File  Delivery  Option .  35 

4.4.10.1  Cost .  35 

4.4.10.2  CDRLs .  38 

4.4. 1 1  Product  Data  File  Delivery  Option  (IQES  Format) .  38 

4.4.11.1  Cost .  38 

4.4.11.2  CDRLs . 38 

4.4.12  Delivery  Option  Advantages .  39 

4.5  Contractor  Validation .  41 

4.5. 1  Validation  by  Contractor  Physical  Configuration  Audit  (PCA)  or 

Verification  Reviews .  41 

4.5.2  TDP  Validation  Report .  41 

4.6  Government  Verification . 41 

4.6.1  Digital  Data  Product  Acceptance . 41 

4.6.2  CITIS  Acceptance .  42 

4.6.3  CALS  IP  Acceptance .  42 


APPENDIXES 

Appendix  A:  Acronyms,  Definitions,  and  Applicable  Documents 
Appendix  B:  Product  Data 

Appendix  C:  Navy  Infrastructure  Modernization  Program 
&  Other  Navy  CALS  Initiatives 

Appendixes  A,  B,  and  C  as  referenced  in  this  document  are  In  tiie  back  of  tiie  Desktop 
Guide. 


IV 


FIGURES 


1 .  TDP  Decision  and  Responsibility  Row  Chart .  7 

2.  Sample  CORL  for  Review  Copies  of  Drawings .  11 

3.  CAi  S  Documents  Relationship .  12 

4.  TDP  Delivery  Format  Selection  Row  Chart .  19 

5.  TDP  Development  Decision  Row  Ch^ .  20 

6.  Nondigital  TDP  Delivery  Decision  Row  Chart .  21 

7.  Partial  Digital  Format  TDP  Decision  Row  Chart .  22 

8.  Select  Delivery  Media  Decision  Row  Chart .  26 

9.  Cost  Estimate  -  Raster .  27 

10.  Sample  CDRL  for  TDP  Elements .  28 

1 1 .  Sample  DD  form  2554-1  Digital  Data  Denoted .  29 

1 2.  Sample  Contract  Attachment  on  *DD  Form  2554-1 ,  BIk  1  .c, 

Digital  Dta  Deliverables* .  30 

13.  Sample  Contract  Attachment  for  Distribution  Statements .  32 

14.  Sample  Attachment  for  DD  Form  1423-1,  BIk  14,  ‘Distribution* .  34 

15.  Cost  Estimate  -  Product  Data  RIes .  36 

16.  Cost  Estimate  -  Native  CAD/CAE  Data  RIes .  37 

17.  Cost  Estimate  -  Product  Data  RIes  -  IGES .  40 

TABLES 

1 .  Advarrfages  and  Disadvantages  of  Deliverable  Options .  39 


V 


(This  page  intentionally  left  blank.) 


1.0  INTRODUCTION 


Computer-aided  Acquisition  and  Logistic  Support  (CALS)  is  a  Department  of  Defense 
(DoD)  strategy  that  will  enable  more  effective  creation,  management,  exchange  and 
use  of  data  to  acquire  and  support  defense  systems  and  equipment.  Technical  data 
packages  (TDPs)  contain  the  information  necessary  to  describe  a  defense  system  and 
its  components  in  terms  of  design,  engineering,  manufacturing,  and  logistics  support. 
Applying  CALS  to  the  creation,  management,  and  use  of  TDPs  will  aid  in  accomplishing 
the  transition  from  paper-intensive  defense  system  acquisition  and  support  processes 
to  an  automated  and  integrated  digital  process. 

It  should  be  noted  that  the  application  of  CALS-related  technologies  to  Navy  processes 
should  be  seen  as  a  means  of  improving  and  streamlining  these  processes  by 
providing  better  methods  of  creating,  managing,  and  using  data,  not  as  a  method  of 
replacing  business  practices. 

1.1  Scope 

It  is  recognized  that  each  defense  system  program  is  unique  with  individual  constraints 
and  access  to  a  distinct  set  of  infrastructure  systems.  This  document  is  intended  to 
provide  the  Navy/Marine  Corps  Acquisition  Manager  with  an  overview  of  Navy  business 
practices  for  the  creation,  management,  and  use  of  TDPs  in  a  CALS  environment. 
Specific  implementation  of  this  process  follows  the  completion  of  the  Government 
Concept  of  Operation  (GCO)  and  may  be  tailored. 

1.2  Purpose 

The  planning  process  for  the  creation,  management,  and  use  of  TDPs  in  a  CALS 
environment  needs  to  take  advantage  of  the  capabilities  provided  by  the  automation 
and  integration  of  information  systems.  Various  data  content,  media  and  format 
options  are  available  for  the  delivery  of  digital  TDPs  needed  to  define  and  support  a 
defense  system.  The  intent  of  this  document  is  to: 

•  Describe  the  various  deliverable  content,  format,  and  media  options  for 
TDPs 

•  Explain  the  benefits  and  caveats  for  the  avaiiable  options 

•  Examine  the  life  cycle  considerations  for  all  options 

•  Describe  the  infrastructure  of  documentation  and  systems  available  to 
support  the  various  options 

•  Provide  a  method  to  determine  the  cost  associated  with  each  option 

•  Provide  guidance  for  specific  contract  language  required  to  support  the 
selection  of  the  options 

•  Describe  contractor  validation  and  Government  verification  procedures. 

This  document  contains  ordering  information  for  the  ouliverable  media  and  digital  data 
format  for  TDPs.  The  guidance  in  this  document  addresses  the  delivery  consideration 
of  TDPs  as  defined  in  MIL-T-31000.  The  Contract  Data  Requirements  List  (CDRL) 
guidance  contained  in  this  document  applies  to  all  TDP  elements. 
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2.0  REFERENCES 


2.1  Acronyms 


A  complete  list  of  acronyms  used  throughout  the  desktop  guide  is  in  Appendix  A.  The 
following  acronyms  are  used  in  this  section  of  the  guide. 


2- D 

3- D 
AIM 
ANSI 
ASCII 
ATIS 
CAD 
CAD-2 
CAE 
CALS 
CALS  RIC 
CALSIP 
CAM 
CCITT 
CD-ROM 
CDRL 
CE 
CGM 
CITIS 
CIVR 
CUN 
COTS 
CTN 
DON 

DID 

DoD 

DoDD 

DoDI 

DTD 

EDI 

EDIF 

EDMICS 

EUN 

EM&D 

FOSI 

GCO 

GR 

lAW 

IGES 

ILS 

I  PC 

IPO 

ISO 


2- Oimension 

3- Oimension 

Advanced  Irtdustrial  Management 

American  National  Standard  Institute 

American  Standards  Coda  for  Information  Interchange 

Advanced  Technical  Information  System 

Computer  Aided  Design 

Computer-Aided  Design  (Second  Acquisition) 

Computer  Aided  Engineering 
Computer-aided  Acquisition  and  Logistic  Support 
CALS  Resource  and  Implementation  Cooperative 
CALS  Implementation  Plan 
Computer  Aided  Manufacturing 

International  Consultative  Committee  on  Telegraphy  and  Telephony 

Compact  Disk  -  Read  Only  Memory 

Contract  Data  Requirements  Ust 

Concept  Exploration 

Computer  Graphics  Metafile 

Contractor  Integrated  Technical  information  Service 

Configuration  Item  Verification  Review 

Contract  Une  Item  Number 

Commercial  Off-The-Shelf 

CALS  Test  Network 

Defense  Data  Network 

Data  Item  Description 

Department  of  Defense 

DoD  Directive 

DoD  Instruction 

Document  Type  Definition 

Electronic  Data  Interchange 

Electronic  Data  Interchange  Format 

Engineering  Data  Management  Information  and  Control  System 
(see  JEDMICS) 

Exhibit  Une  item  Number 
Engineering,  Manufacturing,  and  Development 
Formatting  Output  Specification  Instance 
Government  Concept  of  Operation 
Government-Furnished  Information 
In  Accordance  With 

Initial  Graphics  Exchange  Specification 

Integrated  Logistics  Support 

Institute  for  Interconnecting  and  Packaging 

IGES/PDES  Organization 

International  Organization  for  Standardization 
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JEDMICS 

Joint  Engineering  Data  Management  Information  and  Control  System 

LAN 

Local  Area  Network 

LSAR 

Logistics  Support  Analysis  Record 

MEDALS 

DoD  Military  Engineering  Drawing  Asset  Locator  System 

NDI 

Nondeveiopmental  Item 

NEDALS 

Navy  Engineering  Drawing  Asset  Locator  System 

OCR 

Optical  Character  Recognition 

OS 

Output  Specification 

PCA 

Physical  Configuration  Audit 

PDES 

Product  Data  Exchange  using  STEP 

PDL 

Page  Description  Language 

POSIX 

Portable  Operating  System  Interface 

RDT&  E 

Research,  Development,  Test  and  Evaluation 

SGML 

Standard  Generalized  Markup  Language 

SIE 

Special  Inspection  Equipment 

SNAP 

Shipboard  Non-technicai  ADP  Program 

SOW 

Staternem  of  Work 

SPA 

Solicitation  Package  Automation 

SQL 

Standard  Query  Language 

STEP 

Standard  for  the  Exchange  of  Product  data 

TDP 

Technical  Data  Package 

VHDL 

VHSIC  Hardware  Description  Language 

VHSIC 

Very  High  Speed  Integrated  Circuit 

WAN 

Wide  Area  Network 

WORM 

Write  Once/Read  Many  times 

22.  Definitions 

Definitions  used  in  this  section  and  throughout  the  desktop  guide  are  in  the  Definitions 
section  of  Appendix  A. 

2.3  Applicable  Documents 

Documents  referenced  in  this  section  and  throughout  the  desktop  guide  are  listed  in 
Appendix  A:  Applicable  Documents. 
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3.0  GENERAL  CONSIDERATIONS 


The  development  of  an  acquisition  strategy  for  TDPs  needs  to  be  carefully  examined  to 
maximize  the  value  for  a  specific  defense  system  program.  Program  development 
elements  such  as  technology,  costs,  end-item  quantities,  and  schedules  have  a 
profound  effect  on  the  delivery  requirements  for  supporting  TDPs.  Therefore, 
Acquisition  Managers  must  consider  the  life  cycle  of  the  procurement  and  the  existing 
and  planned  Navy  infrastructure  to  support  the  TDPs  for  their  program. 

The  following  sections  discuss  topics  of  consideration  that  must  be  addressed; 

•  TDP  Bemertts 

•  TDP  Decision  and  Responsibility 

•  Iderrtifying/Establishing  a  TDP  Requirement 

•  TDPs  in  the  CALS  Environment 

•  CALS  Requirer.  jnt  Documents 

•  Infrastructure  Development 

•  Data  Uses. 

Section  4.0,  Specific  Considerations,  uses  these  topics  as  a  basis  to  discuss  specific 
requirements  when  acquiring  TDPs  in  a  digital  environment  such  as:  selection  of  data 
formats  and  delivery  media;  cost  considerations;  and  specific  contract  sample 
language. 

3.1  TOP  Elements 

TDP  elements  may  be  grouped  in  terms  of  data  construction  as:  (1)  Drawings  and 
associated  lists,  (2)  illustrated  text  documents,  and  (3)  product  data.  The  drawings  and 
associated  lists  group  is  data  that  primarily  consists  of  illustrations  that  describe  a 
product  or  process  interspersed  with  small  amounts  of  text  that  help  explain  the 
elements  of  the  product  or  process.  The  illustrated  text  documertt  is  data  that  primarily 
consists  of  text.  In  some  cases  graphics  may  be  present,  but  they  usually  consist  of 
simple  illustrations,  figures,  or  tables.  Product  data  includes  3-D  information,  such  as 
product  models  that  contain  the  digital  information  required  for  full  product  definition 
(see  Appendix  8:  Product  Data). 

3.1 .1  Drawings  and  Associated  Lists 

Each  of  the  types  of  drawings  listed  below  provide  the  data  necessary  to  describe  a 
particular  item  or  product  in  terms  of  illustrations  and  text.  However,  in  terms  of  digital 
data  delivery,  all  of  these  drawings  may  be  delivered  by  either  of  the  following  methods; 
(1)  Raster  image  files  or  (2)  processable  data  files,  which  in  this  case  refers  to  vector 
data  files,  e.g.  native  Computer  Aided  Design  (CAD)  or  Initial  Graphics  Exchange 
Specification  (IGES). 

•  Conceptual  Design  Drawings 

•  Developmental  Design  Drawings 

•  Product  Drawings 

•  Commercial  Drawings 

•  Special  Inspection  Equipment  (SIE)  Drawings 

•  Special  Tooling  Drawings 
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3.1.2  Illustrated  Text  Documentation 


Each  of  the  types  of  documentation  listed  below  provide  the  data  necessary  to  describe 
a  program  or  product  in  terms  of  text  and  simple  graphics.  However,  in  terms  of  digital 
delivery,  all  of  these  documents  may  be  delivered  by  any  of  the  following  methods:  (1) 
Raster  image  files;  (2)  processable  data  files,  which  in  this  case  means  text  files;  or  (3) 
Contractor  Integrated  Technical  Information  Service  (CITIS). 

•  Specifications 

•  Software  and  Software  Documentation 

•  Test  Requirements  Documents 

•  SIE  Operating  Instructions 

•  SIE  Descriptive  Documentation 

•  SIE  Calibration  Procedures 

•  Preservation,  Packagir.g,  Packing,  a^d  Marking  Data 

•  Quality  Engineering  Planning  List 

3.2  TOP  Decision  and  Responsibility 

The  following  sections  of  this  document  are  devoted  to  the  acquisition  of  TDPs  in  a 
digital  environment.  The  purpose  of  the  flow  chart  (see  figure  1)  is  to  lead  ctn 
Acquisition  Manager  through  a  logical  series  of  decisions  designed  to  provide  the  basis 
for  TDP  format  and  delivery  media  selection.  Cost  comparison  information  and 
recommended  CORL  language  is  also  provided. 

The  flow  chart  also  recommends  who  specifically  is  accountable  for  performing  each 
task,  function,  or  making  a  decision.  In  addition  to  identifying  the  responsible  agency  or 
agent  for  each  of  the  tasks,  functions,  or  decisions,  this  chart  also  identifies  supporting 
agencies  and  their  inputs  as  required.  In  many  cases,  these  are  the  same  entity. 

NOTE:  Shadowed  task/function  boxes  alert  the  user  of  additional  details  and/or 
decision  flow  charts. 
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3.3  TDPs  in  the  CALS  Environment 


The  CALS  strategy  provides  the  Acquisition  Manager  with  a  framework  of  standards, 
specifications,  and  systems  (see  Appendix  C:  Navy  Infrastructure  Modernization 
Programs)  to  create,  manage,  and  use  information  in  a  digital  environment  The 
Acquisition  Manager  should  re<'ngnize  the  importance  of  requiring  digital  data 
deliverables.  The  benefits  associated  with  using  digital  data  far  exceed  what  is  being 
discussed  in  this  document  For  TDPs,  two  benefits  of  digital  data  include:  (1) 
Improving  the  handling  and  reducing  the  storage  of  TOP  data,  primarily  engineering 
drawings,  with  electronic  filing  and  archiving,  ideally  creating  a  data  repository  (see 
Appendix  C:  JEOMICS);  and  (2)  reducing  the  costs  associated  with  printing  and 
distributing  TOP  data,  especially  during  the  development  stages,  by  providing  on-line 
access  (CITIS)  (see  Appendix  A)  to  contractor  databases,  so  that  the  Government 
procuring  agency  could  access  specific  TOP  data  required  by  using  any  of  the  methods 
described  in  MiL-H06K-59  (see  3.8). 

Please  note  that  due  to  the  intensive  infrastructure  modernization  efforts  (see  Appendix 
C)  underway  within  the  Navy  and  other  services,  this  document  does  not  consider 
delivery  of  a  TOP  in  other  than  digital  format  justifiable.  References  to  nondigital  data 
deliverables  are  only  made  in  conjunction  with  the  delivery  of  a  digital  product  and  for 
the  sole  purpose  of  verifying  the  quality  and  accuracy  of  the  digital  transfer  of  data 
between  the  various  digital  systems. 

A  brief  discussion  of  both  nondigital  and  digital  data  deliverables  is  provided.  The 
nondigital  deliverables  will  not  be  addressed  again  in  this  document  since  their 
importance  in  a  CALS  environment  is  minimal.  The  digital  deliverables  will  be 
mentioned  here  providing  a  brief  overview  of  options  available  to  the  Acquisition 
Manager.  A  more  thorough  discussion  will  be  provided  in  section  4.0. 

3.3.1  Nondigital  Data  Deliverables  (Originals  and  Reproducibles) 

3.3.1 .1  Paper,  Mylar  Hardcopy 

Paper  or  mylar  hardcopy  has  long  been  the  traditional  media  for  delivery  of  Navy 
product  data  and  related  information.  TDPs  delivered  on  this  medium  may  have 
originated  from  many  sources  including  other  existing  hardcopy  documentation, 
microfiche,  microfilm,  or  any  of  the  digital  data  formats  described  in  the  following 
sections.  Converting  the  data  content  of  paper  to  a  digital  data  format  requires 
infrastructure  systems  that  include  scanning  hardware  and  software  to  support  the 
conversion  of  both  text  and  graphics  from  hardcopy  to  electronic  format.  The  Joint 
Engineering  Data  Management  Information  and  Control  System  (JEDMICS)  supports 
this  type  of  paper  to  digital  format  conversion  process  (see  Appendix  C:  JEDMICS). 

NOTE:  The  Acquisition  Manager  today  should  accept  hardcopy  TDP  deliverables  only 
for  the  purpose  of  veritying  the  digital  deliverables. 
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3.3.1^  Aperture  Cards 

Aperture  cards  is  the  traditional  medium  for  delivery  of  the  TOP  to  the  Navy.  Aperture 
cards  contain  engineering  drawings  on  microfilm  and  associated  engineering  metadata 
in  digital  punch-card  formats.  The  data  provided  on  aperture  cards  are  governed  by 
spedfications,  such  as  MIL-M-38761/2.  MIL-C-9877,  MIL-M-38748.  and  MIL-M-9868. 
which  provide  guidelines  for  data  format  and  content  Because  aperture  cards  contain 
both  microfilm  media  and  digital  punch-card  data,  specialized  infrastructure 
requiremerrfs  are  necessary  to  use  this  media  Single-purpose  systems  are  currently  In 
use  to  extract  the  data  from  aperture  cards.  In  addition,  converting  the  data  contents  of 
aperture  cards  to  a  more  flexible  digital  data  format  would  require  additional 
infrastructure  requirements  that  would  include  scanning  hardware  and  software  to 
support  both  text  and  graphics.  JEDMICS  supports  the  conversion  of  aperture  card 
images  and  data  to  raster  form  (see  Appendix  C:  JEDMICS). 

3.3.2  Diaital  Data  Oeliverabies 

Digital  data  deliverables  available  in  the  CALS  environmertt  are  extensive.  Digital  data 
provides  the  Acquisition  Manager  with  a  variety  of  digital  data  content,  formats  and 
media  options.  They  include  the  following. 

Data  Content: 

•  Drawing  Data 

•  Product  Data 

•  IlluWated  Text  Documents 

Data  Formats: 

•  Text 

a.  Raster 

b.  Unintelligent  Text  (ASCII) 

c.  Intelligent  Text  (SGML  tags,  lliusbations,  etc.) 

•  Image  Data 
a.  Raster 

fc  Native  CAD 

C.  M«»'jtrai 


Media: 


•  Magnetic  tape 

•  Magnetic  disk 

•  Optical  disk 

•  CITIS  -  interactive  on-line  access 

•  CD-ROM 
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3.4  Life  Cycle  Considerations 


As  a  defense  system  develops  through  its  life  cycle,  TOP  deliverable  requirements  may 
vary.  In  addition,  the  availability  as  well  as  the  volume  and  format  of  the  data 
generated  by  the  contractor  changes.  The  Acquisition  Manager  must  be  prepared  to 
adjust  the  contract  data  requirements  to  meet  the  needs  of  all  organizations  involved  in 
the  procurement  and  support  of  the  defense  system.  Often  new  contracts  are  issued  at 
the  Engineering  &  Manufacturing  Development  (E&MO)  (Phase  II)  and  Production  and 
Deployment  (Phase  III)  phases  of  the  acquisition  program;  therefore,  the  Acquisition 
Manager  must  anticipate  the  upcoming  contract  and  be  prepared  to  alter  the  data 
requirements  in  the  procurement  documerrts.  The  Acquisition  Manager  must  also 
consider  the  information  volume  and  typical  use  (see  3.8)  of  the  particular  TDP  element 
selected.  To  take  advantage  of  the  CALS  strategy,  data  must  be  created  and/or 
obtained  in  a  digitai  form  during  the  earliest  possible  program  phase.  By  starting 
early,  product  information  created  during  the  Concept  Exploration  (CE)  and  Definition 
(Phase  0\  phase  may  be  used  repeatedly  throughout  the  life  cycle.  Failure  to  develop 
data  in  a  digital  form  early  in  a  program  can  lead  to  requirements  for  costly  data 
conversion  and  will  deny  potential  benefits  from  digital  data  exchange. 

3.4.1  Contract  Data  Requirements  List  (CORL) 

Standard  practices  of  human  observation,  irrterpretation,  and  review  must  be  used  to 
determine  whether  data  presentation,  format,  and  technical  content  meet  contractual 
requirements  as  specified  in  the  CDRL.  The  transfer  media  is  to  be  verified  by  human 
observation,  interpretation,  and  review  (see  figure  2). 
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CONTRACT  DATA  REQUIREMENTS  UST 

(OMiMm) 


Form  Approved 
0MB  No.  0704^)188 


CONTRACT  UN£rrEM  NO.  8.  EXHISTT 


0.  SYSTHM/ITEM  E.  CONTRACT/PR  NO. 


C.  CATEGORY 
TCP  X  TM 


TM _ OTHER. 


F.  CONTRACTOR 


SEEBLKia 


1  OATAITCMNa  ZTTTUOFCATAfTCM 

PROOUCT  DRAWINGS  AND  ASSOCIATED  USTS 


AAUTX3WTV  S.  OONnUCT  nCRfCNCC 

SEEBLKia 


r  0O2MReo 
CX7 


AAAPCOOe 

A 


lARCMMIKS 

BLX4  a-ORPR-aiOOO.  oo  form  2954-1  with  obioteo  attachments 
AND  MIL-O-54a0  (AOOTYPE.  CLASS  ANO  KMO). 

BLXa-  APPROVAL  SHALL  BE  BASED  ON  COMPLIANCE  WITH 
0t-QRP(V810a0.  MIL-T-3iaOO.  00  FORM  2994-1  ANO  ATTACHMBITS 
OeiOTHS  HEREON..  (ACO  TIME  REQUIRED  FOR  GOVERNMENT 
APPROVAL  ANO  TURNAROUNO  TIME  FOR  CONTRACTOR  TO  RESUBMIT 
DATA  TO  GOVBRNMBfT ) 

BLK9:  TECHNICAL  DATA  SHALLBE  MARKED  (OSTRIBUTION  STATEMBrT 
ANO  EXPORT  CONTROL  WARNMG  NOTICE)  lAW  MIL-STD-iaoe, 
Mtt--STD-100  AND  CORL  SUPPLEMENT  ATTACHMENT.  VENDOR  ITEM 
ORAWMGS  SHALLBE  USED43N  BLOCK  IS  BLANK  OTHSWVISEALL 
RBMINMG  DRAWINGS  SHALL  BE  OISTRiaLmON  SUPPLE^O^T 
(SPEOFY  LETTER). 

BLK14 :  OISTREirnON  SHALL  BE  lAW  CORL  SUPPLBtBTT  ATTACHMOIT.. 


THISISA  SAMPLE  CORL  MFORHATDN  SHOULD  BE 
TALOREO  TO  REFLECT  PROGRAM  REOUREMENTS 


XMITTLE 

REVIEW  COPY  OF  PROOUCT  DRAWINGS 
ELM  (AOO  DATA  ITEM  NO.) 


NOTES;  (1)  COMPLETETHISFORMAW  NSTRUCTDNS  FOR  COMPLETMG 
OOFCRMANOOOOS010.12-Mp1APTB)3).  (2)  COMPLETE  00  FORM 
2554-1  MNML-T-31000  ANO  ATTACH  TO  THIS  FORM.  (ENTB^OGITAL 
DATASPECFCATON.  EXCHANGE  MEDIA.  ETC  ..  NTO  BLOCK  I  .C.) 

(3)  COMPLETE  ATTACHLENT(S)  FOR  00  FORM  2994-1  ANO  CORL 
SUPPLEMENT  TO  ACCOMPANY THB  FORM. 


K  04IE  j 

1.  APPtK^eosf 

J.  OATE 
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3.5  CALS  Requirements 


Standards  and  specifications  have  been  developed  and  are  continuing  to  be  developed 
to  assist  in  providing  a  baseline  of  standardization  to  the  CALS  strategies  and 
processes.  These  documents  provide  the  policies  and  procedures  to  define  and 
coordinate  data  acquisition  during  development  of  new,  and  maintenance  of  existing 
defense  systems.  Rgure  3  provides  a  chart  displaying  the  relationship  of  each  of  the 
CALS  documents  to  data  acquisition.  CALS  standards  and  specifications  pertaining  to 
the  acquisition  of  TDPs  are  included  in  Appendix  A 


3.6  Infrastructure  Development 

Effective  acquisition  of  digitai  data  can  only  be  done  with  full  consideration  of  the 
ability  of  Naval/Marine  activities  to  receive,  store,  distribute,  and  use  the  digitai 
data  that  compn<*s  with  the  CALS  standards.  The  Acquisition  Manager  must 
establish  the  uses  for  which  the  data  is  required  (see  3.8)  and  the  infrastructure 
modernization  programs  (see  Appendix  C)  available  to  support  this  data.  In  response 
to  DoOl  5000.2,  DoO  components  are  incrementally  upgrading  the  infrastructure  toward 
a  comprehensive  technical  information  management  architecture  through  joint  service 
programs  like  JEDMICS  (see  Appendix  C).  The  evolution  of  this  infrastructure  is  a  key 
consideration  in  implementing  the  CALS  strategy  on  any  given  acquisition. 
Deficiencies  in  program  related  infrastructure  may  require  cost  investments  by  the 
acquisition  management  team  to  effectively  implement  the  CALS  strategy. 

The  availability  of  digital  data  processing  and  telecommunications  technology  and 
approved  standards  for  creation  management,  storage  management,  transmission, 
data  protection,  and  integrity  of  data  at  the  time  of  delivery  or  access  are  important 
criteria  for  acquisition  decisions.  The  current  and  projected  capabilities  of  both  the 
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contractor  and  Naval  Forces  components  must  be  assessed  with  respect  to  program 
needs  and  schedules.  The  Government  Concept  of  Operation  (GCO),  its  'C<»itractor's 
approach  to  CALS  Implementation'  counterpart,  and  CALSIP  (when  required),  are 
excellent  vehicles  for  making  these  determinations.  Acquisition  managers  must  plan  to 
acquire  and/or  access  digital  data  products. 

The  data  user  infrastructure,  the  computing  environment  available  to  a  particular  user, 
must  be  considered  when  acquiring  digital  data.  This  environment  establishes  the  data 
processing  capabilities  of  that  user.  The  following  areas  identify  a  user's  infrastructure: 

•  Hardware;  Determine  the  current  and  planned  hardware  available  to  support 
the  defense  system  program. 

•  Software:  This  is  the  most  critical  element  Interoperability  will  normally  be 
achieved  through  the  use  of  software.  Again,  determine  both  present  and 
future  software  applications  and  availability. 

•  Networks:  Determine  the  local*  and  wide-area  networking  (LAN  and  WAN) 
capabilities  and  whether  CITIS  will  be  used. 

The  Navy  infrastructure  modernization  programs  specifically  designed  to  aid  in  the 
creation,  management,  and  use  of  TDPs  are: 

•  CAD-2:  Computer-Aided  Design  (Second  Acquisition) 

•  JEDMICS:  Joint  Engineering  Data  Management  Information  and  Control 
System 

•  NEDALS;  Navy  Engineering  Drawing  Asset  Locator  System 

•  AIM:  Advanced  Industrial  Management 

•  ATIS;  Advanced  Technical  Information  System. 

An  overview  of  these  information  management  infrastructure  programs  is  contained  in 
Appendix  C. 

3.7  Data  Uses 

Technical  data  packages  are  subject  to  all  uses  defined  in  MIL-HDBK-59.  The 
Acquisition  Manager  will  need  to  identify  the  use  of  the  data  by  all  organizations 
involved  in  the  acquisition  program.  The  Acquisition  Manager  must  consider  how  data 
will  be  processed  in  order  to  make  good  decisions  on  digital  data  requirements.  The 
five  categories  of  data  processing  typical  of  most  defense  system  programs  are: 

•  View  only;  The  ability  to  examine  a  data  file  without  the  ability  to  change  it. 
This  includes  viewing  selected  portions  of  one  or  several  documents  as  well  as 
side-by-side  comparisons  of  documents.  This  activity  is  an  excellent  candidate 
for  applying  the  CITIS  concept. 
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•  Comment/Annotate:  The  ability  to  evaluate  and  highlight  for  future  reference  or 
to  make  annotations,  approvals,  and  comments  without  the  ability  to  change  the 
original  file.  Annotations  are  associated  with  a  specific  item  or  location  within  a 
document  and  are  displayed  whenever  that  point  or  area  of  the  document  is 
displayed.  Core  CITIS  functions  (approve,  comment,  view)  are  intended  to 
provide  this  capability  and  should  be  given  consideration. 

•  Update/Maintain;  The  ability  to  change  data  either  directly  or  through  controlling 
software  in  the  active  files  on  the  host  computer. 

•  Extract/Process/Transform:  The  ability  to  extract  and  modify  the  format, 
composition,  and  structure  of  the  data  into  another  usable  form. 

•  Archive:  The  placing  of  data  into  a  repository  to  preserve  it  for  future  use. 

The  interchange  nf  text  type  data  that  traditionally  has  been  conveyed  on  paper  can  be 
transmitted  or  communicated  electronically  using  the  established  rules  and  formats  of 
Electronic  Data  Interchange  (EDI).  The  Federal  information  Processing  Standard 
(FIPS)  publication  FIPS-PUB-161  for  EDI  is  recognized  as  the  international  standard  for 
the  electronic  transmission  of  data  associated  with  functional  documents,  such  as  a 
purchase  order  or  invoice. 
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4.0  SPECIFIC  CONSIDERATIONS 


4.1  TDPOeliv0ry 

The  purpose  of  this  section  is  to  determine  the  status  and/or  existence  of  a  TOP  and 
ultimately  to  lead  the  Acquisition  Manager  to  a  decision  as  to  the  specific  type  of  digital 
data  and  meda  format  required  to  support  his  or  her  program.  In  addition  to  the 
immediate  TOP  requirements  (acquire  and/or  develop  an  end  item  or  system),  the 
Acquisition  Manager  should  consider  the  potential  long  term  engineering  and  S(4)port 
functions  and  requiremerrts  for  technical  data  when  selecting  TOP  formats. 

4.1.1  Potential  TOP  Delivery  Options 

While  actual  delivery  may  include  a  mixhire  of  options,  TOP  information  fails  into  three 
distinctly  different  delivery  forms: 

•  Document  (drawing  image):  Hard  copy  (nondigitai  discussed  in  3.4.1)  or  digital 
images  (raster). 

•  Processable  Data  RIes:  CAO  data  and  Computer  Aided  Engineering  (CAE) 
systems  create  vector  graphic  files  that  define  the  geometry  and  associated 
data  attributes  of  defense  systems  assemblies,  subassemblies,  and 
components.  Data  generated  in  this  manner  is  capable  of  being  updated; 
hence,  the  files  containing  data  are  processable.  In  defense  system 
development  contracts,  digital  delivery  of  processable  data  files  is  preferred  and 
should  be  considered  the  standard  of  communication  between  the  contractor 
and  the  Government. 

•  CITIS  interactive  access:  Consult  MIL-STD-974  for  interactive  access/delivery 
options. 

4.1 .1.1  Raster 

Raster  data  is  a  binary  representation  of  an  image.  Raster  may  be  thought  of  as  the 
electronic  version  of  a  paper  document.  It  contains  no  ’intelligence*  and  must  be 
reviewed  through  human  interpretation.  There  are  two  types  of  raster  data,  tiled  and 
untiled.  Tiled  raster  is  the  preferred  format  because  of  smaller  file  size.  A  tiled  raster 
image  resembles  a  two-dimensional  grid  with  each  *tile*  or  set  of  pixels  representing  a 
portion  of  the  image.  Text  and  graphics  in  raster  data  formats  are  stored  digitally, 
wNch  allows  more  rapid  and  consistent  access  to  the  stored  images  than  paper.  In 
addition,  raster  data  can  be  sent  via  electronic  means  to  remote  sites.  Raster  files  can 
be  edited  in  several  ways: 

•  Raster  Edit:  The  manipulation  of  individual  pixels  or  pixel  groups 

•  Vector  Overlay:  Hybrid  editing  where  vectors  are  overlaid  onto  a  raster  file  (both 
the  raster  and  vector  are  stored  as  the  final  image) 

•  Raster  to  Vector  Conversion:  Conversion  of  pixel  groups  to  vector  primitives. 

Raster  documents  may  be  converted  to  unintelligent  text  via  Optical  Character 
Recognition  (OCR)  technology.  The  technology,  however,  is  still  in  its  infancy. 
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With  the  advent  of  raster  scanning  technologies,  the  ability  to  convert  existing  TDPs  to 
digital  data  files  has  become  available.  However,  the  quality  assurance  process  (by 
human  interpretation)  required  to  verify  the  data  contents  may  increase  costs 
substantially.  Also,  raster  image  files  require  a  large  amount  of  memory  storage  due  to 
their  file  structure  and  contain  no  additional  information  other  than  each  tile's  position 
on  a  grid.  Because  of  these  drawbacks,  the  Acquisition  Manager  should  consider 
processable  data  forms  before  considering  raster  unless  the  TOP  will  not  be  used  for 
competitive  reprocurement.  JEOMICS  stores  drawing  images  as  raster  data  on  optical 
disk  media  and  will  accept  tiled  or  untiled  raster  data  (see  Appendix  C:  JEOMICS). 

4.1. 1.2  Processable  Data  Files 

Processable  data  files  provide  the  majority  of  options  available  for  digital  TOP  delivery. 
Processable  data  files  can  be  broken  down  into  two  additional  categories,  drawing  and 
product  data  files  and  text  data  files.  These  categories  are  considered  processable, 
because  the  data  can  be  manipulated  by  the  user,  interpreted  by  the  computer,  and 
reprocessed  into  an  updated  or  new  form  as  specified  by  the  user. 

4.1.1 .2.1  Drawing  and  Product  Data  Files 

Drawing  data  files,  the  output  of  CAD  systems,  comprise  vector  data,  and  as  the  name 
“vector"  implies,  the  image  produced  is  composed  of  vectors,  a  sequence  of  line 
segments.  Vector  data  provides  geometrical  and  physical  representation  of  objects  in 
both  two  and  three  dimensions.  Vector  data  files  are  stored  digitally  allowing  rapid 
retrieval  and  integration  Into  other  compatible  systems.  Because  the  data  consists  of  a 
sequence  of  line  segments  and  pattems/symbols  that  represent  entities  with  specific 
orientation  and  location,  vector  data  can  be  translated  to  code  interpreted  by  some 
automated  machine  tools.  Drawings  delivered  in  this  format  must  conform  to  IGES 
Class  II  (MIL-D-28000)  unless  the  native  vector  CAD  files  are  available  in  an  agreed-to, 
compatible  format.  (The  user  of  native  vector  data  must  have  the  same  type  of  CAD 
system  or  must  have  a  direct  translator  from  the  source  system  to  the  using  system.) 
The  native  CAD  format  is  the  preferred  format  during  early  development  phases  in  the 
defense  system  program's  life  cycle,  because  the  translation  to  IGES  will  invariably 
exclude  some  of  the  data  inherent  in  the  native  CAD  files.  If  vector  data  is  not 
compatible  between  the  user  and  the  source,  then  the  IGES  standard  should  be 
delivered,  as  it  does  allow  dissimilar  CAD  systems  to  manipulate  vector  data  Rnal 
delivery,  however,  must  be  in  IGES.  CAD-2  supports  vector  data  in  IGES  formats  (see 
Appendix  C;  CAD-2). 

Note:  There  are  no  commercial  or  Government  standards  for  preparing  3-D  CAD 
models.  As  a  result,  repository  systems  may  not  have  the  capability  to  store  usable  3-D 
CAD  products. 

Acquisition  Managers  should  consider  acquiring  the  portion  of  the  drawing  package 
developed  from  3-D  modeling. 

Product  data  is  the  most  comprehensive  form  of  digital  data.  Product  data  contains  all 
information  needed  to  describe  a  product  completely,  and  a  large  portion  of  this 
information  can  be  directly  interpreted  by  a  computer.  Product  data  allows  the 
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simuiation  of  systems  modifications  prior  to  implementation  and  evaluation  of  form,  fit 
and  function  performance  of  components.  In  addition,  product  data  with  its  inherent 
intelligence  can  be  used  to  drive  manufacturing  processes. 

4.1 .1J2^  Illustrated  Text  Data  Files 

Illustrated  text  data  files  provide  a  dynamic  form  of  source  data  with  two  possibilities: 
(1)  Separated  files  for  text,  graphics,  alphanumeric,  and  audio/visual  data;  or  (2) 
integrated  files  consolidating  some  or  all  of  these  different  data  representations.  Text 
data  files  irKlude  word  processing  and  desk  top  publishing  applications.  Such  data 
files  can  provide  the  source  data  for  multiple  data  applications  that  allow  creation  of 
standard  and  custom  documents  as  well  as  manipulation  of  the  data  for 
anrratale/excerpt  or  update/maintain  purposes.  Text  data  files  can  also  import  generic 
text  [ASCII,  SGML  (MIL-M-28001).  etc.]  and  graphics  [raster  (MIL'R'28002),  CGM 
(MIL-0-28003),  IGES  (MIL-0-28000),  etc.]  from  other  sources  that  may  be  o^erwise 
incompatible.  Also,  there  are  Page  Doscription  Languages  (POLs),  sometimes  called 
text  presentation  metafiles,  which  are  used  to  drive  output  devices  such  as  printers. 

There  may  be  instances  when  obtaining  text  data  files  involves  obtaining  more  than 
one  format  of  graphical  data.  This  may  be  due  to  multiple  graphic  sources.  This  is  an 
acceptable  and  highly  likely  situation.  The  Acquisition  Manager  must  be  aware  of  this 
possibility  and  be  prepared  to  develop/modify  the  defense  system  contract 
requirements  accordingly. 

Text  Formats; 

There  are  three  possible  text  formats  available  for  consideration  when  invoking  the 
option  specifying  text  data  files.  They  are  American  Standards  Code  for  Information 
Interchange  (ASCII)  and  tagged  ASCII,  Standard  Generalized  Markup  Language 
(SGML),  or  raster.  They  are  described  below. 

•  ASCII 

ASCII  was  developed  as  a  method  of  translation  for  computer  processors  to 
interpret  alphanumeric  characters  and  symbols  through  binary  representation. 
ASCII  is  the  basic  text  information  used  by  most  wordprocessing  applications 
and  contains  no  formatting  information  other  than  line  feed  and/or  carriage 
returns.  Wordprocessing  applications  can  import  ASCII  text  from  other 
wordprocessing  applications,  and  some  wordprocessing  applications  can 
translate  formatted  ASCII  from  other  wordprocessing  applications  into  their  own 
format.  This  makes  ASCII  text  ideal  for  most  interim  deliverables  since  it  can 
also  be  imported  into  an  SGML  application  where  it  can  be  SGML-tagged  to 
become  a  CALS-compiiant  deliverable. 

•  SGML 

SGML  as  defined  in  MIL-M-28001  is  "A  standard  that  defines  a  language  for 
document  representation  which  formalizes  markup  and  frees  it  of  system  and 
processing  dependencies.  It  provides  a  coherent  and  unambiguous  syntax  for 
describing  whatever  a  user  chooses  to  identify  within  a  document."  In  the 
SGML  scheme,  the  document  contains  only  generic  tags  identifying  such 
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structuraJ  elements  as  paragraphs,  sections,  etc.  but  no  typesetting  markup. 
However,  SGML's  tagging  of  ASCII  text  is  a  rather  cumbersome  proposition  and 
may  be  best  suited  for  final  data  deliverables  rather  than  interim  deliverables. 
When  considering  SGML  as  a  deliverable  format,  the  Acquisition  Manager  must 
determine  whether  the  necessary  computer  environment  is  available  and  in 
place  to  accept  the  SGML  documentation.  Additional  features  associated  with 
SGML  are  described  in  Appendix  A  pocument  Type  Definition  (DTD),  Output 
Specification  (OS),  Formatting  Output  Specification  Instance  (FOSI)]. 

•  Raster 

See  4.1.11  for  a  discussion  of  raster  data. 

Graphics  and  Illustration  Formats; 

There  are  many  possible  graphic  image  formats  available  for  consideration  when 
invoking  the  option  of  specifying  text  data  files.  Two  suggested  formats  described 
below  are  Computer  Graphics  Metafile  (CGM)  and  raster. 

•  CGM 

CGM  data  is  a  two  dimensional  vector  preserrtation  used  primarily  for  charts, 
figures,  and  simple  drawings.  CGM  requirements  are  stated  in  MIL-O-28003. 

•  Raster 

See  4. 1 . 1 . 1  for  a  discussion  of  raster  data 
Page  Description  Language  (PDL): 

A  PDL  file  is  executed  by  an  interpreter  that  controls  a  raster  printer  or  other  output 
device.  A  PDL  can  be  used  to  ensure  that  the  composed  document  produced  by  an 
electronic  publishing  system  (which  may  impose  additional  processing  limitations,  such 
as  font  variations,  kerning,  or  hyphenation)  would  produce  nearly  identical  hardcopy 
output  on  the  widest  possible  spectrum  of  printer  devices.  MIL  STD- 1840  provides  for 
the  interchange  of  PDL  data  files.  However,  PDLs  are  currently  not  standardized,  for  a 
Standard  Page  Description  Language  (SPDL)  is  still  being  developed.  MIL-STD-1840 
requires  that  a  system  must  provide  portability  of  files  (e.g.:  Postscript  or  Impress  PDL 
specifications).  PDL  document  image  files  can  be  acquired  as  interim  deliverables  or 
as  final  deliverables  in  addition  to  (but  not  in  place  of)  other  digital  data  deliverables. 

4.2  Existing  TOP  Availabiiity 

Utilization  of  existing  legacy  data  is  quite  common  when  new  systems  use  features  of 
older  systems.  The  Acquisition  Manager  should  be  aware  that,  even  on  completely 
new  defense  system  programs,  some  portion  of  the  TDP  may  pre-exist  (see  figure  4). 
This  is  most  relevant  when  a  program  is  entering  the  Concept  Exploration  and 
Definition  (Phase  0)  and  prior  to  Concept  Demonstration  Approval,  Acquisition 
Milestone  I.  An  important  point  to  remember  here  is  that  acquisition  of  the  proper  level 
and  type  of  digital  data  is  most  cost  effective  when  defined  early  in  the  program's  life 
cycle.  Other  potential  considerations  include:  TDPs  associated  with 
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Nondevelopmental  Items  NOIs),  Commercial  Off-The-Shelf  (COTS)  acquisitions,  and 
reverse  engineering  efforts.  If  the  TOP  does  not  exist  and/or  is  not  accessible  to  the 
Government,  the  Acquisition  Manager  should  refer  to  the  TOP  development  decision 
flow  chart  (see  figure  5  and  section  4.4).  If  a  TOP  does  exist,  the  Acquisition  Manager 
should  proceed  to  4.3  regarding  the  format  of  the  TOP.  Please  note  that  for  those 
cases  where  the  TOP  is  under  development  but  not  yet  completed,  the  Acquisition 
Manager  also  should  proceeo  lo  4.3. 


FIGURE  4.  TOP  Delivery  Format  Selection  Flow  Chart 

4.3  TOP  Format  Determination 

Assuming  the  existence  of  a  TOP,  the  Acquisition  Manager  must  consider  whether  any 
portion  of  the  TOP  exists  in  a  digital  format.  Again,  the  purpose  is  to  lead  the 
Acquisition  Manager  into  another  series  of  questions  to  define  further  which  digital 
delivery  format  best  satisfies  the  defense  system  program  objectives  and  requirements. 
Potential  concerns  here  include;  (1)  TDPs  associated  with  existing  in-service  items  that 
may  or  may  not  be  in  digital  format;  (2)  new  TDPs  that  potentially  could  be  developed  in 
a  nondigital  format;  and,  most  likely,  (3)  TDPs  that  are  a  varying  mixture  of  digital  and 
nondigital  elements.  If  the  TDP  does  not  exist  in  a  digital  format,  refer  to  figure  6  as 
you  read  the  following  sections.  If  the  TDP  does  exist  in  a  digital  format,  refer  to  figure 
7  as  you  read  the  following  sections. 


19 


4.4  TOP  Development  Decision 


The  Acquisition  Manager  must  logically  decide  which  TDP  delivery  format  best  fits  the 
life  cycle  of  the  weapon  system.  This  decision  flow  chart  (see  figure  5)  is  formed 
around  the  premise  that  the  TDP  will  be  delivered  in  some  type  of  digital  format  with  the 
only  question  being  which  format  best  fits  the  needs  and  requirements  of  the  program. 
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FIGURE  6.  Nondigital  TOP  Delivery  Decision  Flow  Chart 


21 


FIGURE  7.  Partial  Digital  Format  TDP  Decision  Flow  Chart 
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4.4.1  Government  Maintenance  and  Control  of  the  TOP 

The  Acquisition  Manager  must  consider  whether  the  Government  plans  to  maintain  and 
control  the  TOP  internally.  This  deals  with  the  underlying  issues  of  who  will  maintain 
and  control  the  TOP  once  it  has  been  delivered  to  the  Government  and  how  will  they  do 
it  It  is  assumed  ^^t  the  TOP  will  be  developed  in  a  digital  environment  i.e.  in  a 
CAO/CAE  environment.  The  key  point  to  remember  is  that  if  the  Government  plans  to 
maintain,  update,  and/or  produce  various  c(xifigurations  of  the  TOP  in  the  future,  the 
TOP  should  be  delivered  in  an  'intelligent*  formal,  i.e.  in  processable  data  files 
including  CAO/CAE  files  vice  dociment  image  files  such  as  raster  format  Conversely, 
if  the  Government  does  not  plan  to  'update  or  maintain'  the  TOP,  it  is  recommended 
that  the  Acquisition  Manager  consider  a  raster-format-oniy  delivery.  If  the  Goverrvnent 
plans  to  maintain  and  control  the  TOP  internally,  go  directly  to  4.4.3.  Otherwise,  go  to 
4.4.2. 

Note:  Oelivery  of  a  TOP  in  raster  format  ooes  not  eliminate  on-line  or  electronic  type 
review,  comment,  and  annotation  options  during  the  TOP  development  cycle. 

4.4.2  Competitive  Reprocurement 

The  Acquisition  Manager  must  consider  whether  competitive  reprocurement  of  the 
system,  spares,  and  follow-on  support  is  planned.  This  prompts  the  Acquisition 
Manager  to  consider  future  requirements  for  the  TOP.  Competitive  procurements,  as 
addressed  in  the  Acquisition  Plan,  can  be  significantly  enhanced  with  the  availability  of 
'InteHlgenf.  digital  information  such  as  Government-Furnished  Information  (GFI)  to  the 
prospective  bidders.  If  future  acquisitions  are  not  anticipated,  cost  associated  with 
delivery  of  the  TOP  in  a  processable  data  file  format  may  be  unwarranted.  If 
competitive  reprocurement  is  planned,  delivery  of  an  'inteHigenf  format  such  as 
processable  data  files  is  recommended.  In  this  case,  go  to  4.4.3.  If  competitive 
reprocurement  is  not  planned,  delivery  of  an  'intelligent*  data  format  may  not  be  cost 
effective,  and  a  raster  format  is  recommended.  In  this  case,  go  to  4.4.8. 

4.4.3  TOP  Modification/Revision  Determination 

Next  the  Acquisition  Manager  should  consider  whether  the  Government  anticipates 
revising  and/or  modifying  a  significant  portion  of  the  TDP  in  the  future.  This  applies 
only  to  the  nondigital  portion  of  the  TDP.  This  prompts  the  Acquisition  Manager  to 
determine  whether  the  nondigital  portion  of  the  TDP  would  serve  the  defense  system 
program  better  in  a  digital  format.  If  future  manipulation  of  the  data  is  not  anticipated, 
raster  delivery  is  the  most  suitable  option.  Proceed  to  4.4.8.  If  the  Government  does 
plan  to  revise  and/or  modify  the  TDP,  additional  digital  data  considerations  must  be 
addressed.  Go  to  4.4.4. 

4.4.4  Digital  System/Environment 

The  Acquisition  Manager  should  now  determine  whether  the  contractor's  native  digital 
environment/system  is  known  at  this  time.  This  is  focused  at  determining  the  most 
economical  and  efficient  format  for  the  various  TDP  components.  (It  is  assumed  that 
the  Government  has  previously  completed  a  GCO  and  identified  the  applicable 
Government  in  place  infrastructure.)  Obviously,  for  competitive  procurements  prior  to 
source  selection,  the  contractor's  digital  environment  will  not  be  known.  This  is,  of 
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course,  unless  ail  prospective  contractors  have  identical  digital  environment/systems.  If 
the  contractor's  digital  environment  is  not  known,  go  to  4.4.7,  which  will  consider  the 
delivery  of  2-0  and  3-0  CAO/CAE  data  files  vice  the  delivery  of  a  more  comprehensive 
set  of  product  data  files.  Otherwise,  proceed  to  4.4.5. 

4.4.5  Digital  System/Environment  Compatibility 

Next  the  Acquisition  Manager  must  determine  whether  the  contractor's  and  the 
Government's  digital  environments/systems  are  compatible.  This  focuses  on  the 
potential  of  transferring  processable  data  files  directly  between  two  similar  systems  vice 
the  transfer  of  data  through  a  neutral  data  format  such  as  IGES.  Since  the  transfer  of 
data  between  similar  systems  is  typically  less  time  consuming  and  is  more  accurate, 
this  type  of  transfer  is  recommended.  However,  where  the  two  systems  are  not  similar, 
the  transfer  of  data  via  a  neutral  format  is  recommended  and/or  quite  necessary,  if  the 
digital  environments  are  compatible,  it  is  recommended  that  the  transfer  of  data 
between  the  contractor  and  the  Government  be  in  the  contractor's  native  format. 
Proceed  to  4.4.6.  If  the  digital  environments  are  not  compatible,  it  is  recommended 
that  a  neutral  format,  such  as  IGES,  be  used  to  transfer  data  between  the  contractor 
and  the  Government.  In  this  case  go  to  4.4.7. 

4.4.6  TDP  Data  Requirements  (Compatible  Systems) 

The  Acquisition  Manager  should  now  determine  whether  product  data  files  are  required 
in  addition  to  2-0  and  3-0  CAO/CAE  drawings.  This  draws  the  Acquisition  Manager's 
attention  to  what  specific  elements  of  the  TOP  should  be  delivered  to  and/or  made 
accessible  to  the  Government.  This  is  based  on  the  assumption  that  the  contractor's 
digital  environment/system  is  compatible  with  the  Government's. 

Product  data  files  will  not  be  necessary  if  only  2-0  and  3-0  engineering  drawings,  parts 
lists,  and  specifications  are  required.  In  this  case,  go  to  4.4.10.  If  it  is  determined  that 
product  data  files  are  required,  proceed  to  4.4.9.  Additional  product  data  files  that  the 
Acquisition  Manager  should  consider  might  include  manufacturing  data,  simulation 
models  and  data,  packaging  data,  etc.  (see  4. 1.1. 2.1  NOTE). 

4.4.7  TDP  Data  Requirements  (Incompatible  Systems) 

The  Acquisition  Manager  should  now  determine  whether  product  data  files  are  required 
in  addition  to  2-0  and  3-0  CAO/CAE  drawings.  This  dravrs  the  Acquisition  Manager's 
attention  to  what  specific  elements  of  the  TOP  should  be  delivered  to  and/or  made 
accessible  to  the  Government.  This  is  based  on  the  assumption  that  the  contractor's 
digital  environment/system  is  either  unknown  or  is  different  from  the  Government's. 

Product  data  files  will  not  be  necessary  if  only  2-0  and  3-0  engineering  drawings,  parts 
lists,  and  specifications  are  required.  In  this  case,  go  to  4.4.1 1.  If  product  data  files  are 
required,  proceed  to  4.^  .9.  Additional  product  data  files  that  the  Acquisition  Manager 
should  consider  might  include  manufacturing  data,  simulation  models  and  data, 
packaging  data,  etc.  (see  4.1. 1.2.1  NOTE). 
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4.4.8  Raster  Delivery  Option 

The  raster  delivery  option  (see  figure  8),  which  is  described  in  section  4.1. 1.1,  allows 
the  Acquisition  Manager  to  obtain  TOP  data  in  a  digital  format.  The  data  uses  of  the 
raster  deliverable  are  somewhat  limited  but  do  provide  for  view,  archive,  comment,  and 
annotate  capabilities.  Suggested  delivery  media  options  include;  (1)  Optical  disk  or 
CD-ROM,  (2)  magnetic  disk,  or  (3)  9-track  magnetic  tape,  ail  in  accordance  with  MIL- 
STD-1840.  Paper  documentation  may  be  requested  in  addition  to  the  raster 
deliverables  but  only  for  verification  of  the  raster  data  content. 

4.4.8.1  Cost 

Once  raster  has  been  selected  as  the  data  delivery  format,  the  cost  of  acquiring  fois 
data  can  be  calculated.  A  chart  (see  figure  9)  has  been  developed  to  assist  the 
Acquisition  Manager  in  estimating  this  cost  This  six-step  process  includes  cost 
estimates  for  both  raster  and  paper  deliverables.  If  paper  deliverables  are  not  required 
for  verification  as  in  the  early  stages  of  the  defense  system's  life  cycle,  they  may  be  left 
out  of  the  cost  estimate  by  skipping  step  3. 

Note:  This  chart  will  provide  an  approximation  of  costs  associated  with  this  data 
deliverable.  Specific  program  requirements,  especially  labor  rates,  may  vary  from 
those  presented  here  and  may  be  substituted  for  the  rates  shown. 

4.4.8.2  CORLs 

To  invoke  tills  data  deliverable  option,  specific  CORLs  (see  figures  10  through  14)  have 
been  developed  to  be  used  as  examples.  The  information  contained  in  these  contract 
vehicles  should  be  tailored  to  meet  the  requirements  of  the  specific  defense  system 
program.  The  CDRL(s)  must  include  language  that  specifies  exactly  how  data  will  be 
delivered  (including  media,  format,  and  content)  under  the  contract.  CALS  standards 
and  specifications  should  be  invoked  whenever  possible. 

4.4.9  Product  Data  RIe  Delivery  Option 

Product  data  files  (see  figure  8)  consist  of  a  variety  of  data  delivery  options  including 
product  data  files,  text  data  files,  and  Product  Data  Exchange  using  Standard  for  the 
Exchange  c*  Product  data  '”0 IS).  POES,  which  has  been  included  in  figure  8,  will  not 
be  includeo  estimate  since  this  data  format  is  currently  under  development 

and  is  not  li  ickiui  e  '  c  nough  to  be  considered  as  a  delivery  option  at  this  time.  Product 
data  files  and  text  data  files  are  described  in  various  subsections  of  4.1,  and  a 
discussion  of  "Intelligent*  data  is  provided  in  Appendix  B.  These  data  deliverables 
provide  ail  the  data  uses  described  in  MIL-HDBK-59  including  view,  archive,  comment 
annotate,  extract,  process,  and  transform.  Suggested  delivery  media  options  include; 
(1)  Optical  disk,  (2)  magnetic  disk,  or  (3)  9-track  magnetic  tape,  all  in  accordance  with 
MIL-STD-1840.  Paper  documentation  may  be  requested  in  addition  to  the  digital  data 
deliverables  but  only  for  verification  of  the  digital  data 
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FIGURE  8.  Select  Delivery  Media  Decision  Flow  Chart 


FIGURE  9.  Cost  Estimate  -  Raster 
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DO  FORM  1 4Zr  ANO  OOO  S010.12M  (CHAPTBT  3).  iNCLUOE  REF5TENCE  TO 
00  FORM  2S54- 1 .  CORL  SUPPLEMB4T  ATTACHM9rT(S) .  ANO  ATTACHMBa(S) 
AS  NEEDED.  (3  COMPLETE  DO  FORM  2554-1  lAW  MIL-T-31000  (STTER 
DIGITAL  OATASPEORCATION.  EXCHANGE  MEDA.  ETC.  IN  BLOCK  1.C  OR 
VIA  CONTRACT  ATTAOMBTT  (3)  COMPLETE  ATTAOWBfr(S)  FOR  DO 
FORM  25S4-1  ANO  CORL  SUPPIEMSTT. 


a  PRCPAMD8V 

H.  DATE 

1 

J.  DATE 
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TOP  option  SafCnON  WORKSHEET 

PRODUCT  DRAWINGS  AND  ASSOCIATED  USTS 


A.  CONTIWCT  NO. 


a  eMaTMTTACHMET  NO. 


0.  com.  DATA  ITBA  NO. 


I 


A  OW>OINAL$Ci—n  mil)  PMA  He.) 


a  n^nooucnONS  ttmahf  ttaatemon,  tlf.  €iam.  me.,  maquum/ at  mehi 


c  OiqiTAL  DATA  td—Hf  tpAafUM.  MaNWgi  ctPa  PC.) 

See  contract  attachment  Ibr  00  Fotm  2554-1  Oisital  Oau  Oelivorablaa 


i  CAflEcooEAMioocuMeffmiiagnsaaiw 


ACONTnACTOR 


B, 


a  oovevais<T(CaiiaMM(i)«M(qar(s 


(l)Uaa  CADE  Com 

CS  Um  Ooeunam  NuRMB 

flToSaAaaviaPBy: 

A  CONTRACTOR  FORMATS  FoiraHM 


a  OOveiNMCNT  FORMATS  Foim  M  M  aeRliad  by  oonmoor. 
SanplM  bueelMd  by  (SpKFy) 


cOOVERNMOyr  FORMATS  Fonrn  lo  bb  aeRMb  < 
Oonn—nt  Ftfwhbb  Mmim  by  (SpbcCyl 


4  TYPES  ANOQUANTTTY  OF  ORAWINOSSeLBmON 


A  CONTRACTOR  aaecTs 


a  oouERNMerr  sascrs  (StMoiy «  MM  R 


S  ASSOCIATED  USTS  0(«M 


A  PARTS  USTS  (XbM) 


a  DATA  USTS  (XonR 


c  INDEX  USTS  (X  ana) 


a  details  0(  on*) 


(1)  IIMRM 


(l)NalRKiUMd 


(DNNRMUMd 


(3)  CaneasHn  Opbbn 


O)  npujibb  (SpacSy  of  MMiiaiy) 


g)  Roquibd  (Mbofy  Nmn  of  ■UMblyl 


n 

A  MULT10ETAIL  ORAWINOS  PERMITTED 

a  monooetail  orawinos  mahoatory 

A  NOT  REQUREO.  ML-T-3100a  para  SS  Maa  not  apply. 


a  REQUIRED.  ML-T-Sioao  para  SS  appPoA  OuMKy  aaau 


iiarajramaiaiofialfbadoeijiiaraabaiQAPyoacoordaneat 


(1)  OARCOM  Foim  24SAR  Raqiaiad 

u 

(2)  OARCOM  Fofm  24SAR  Nol  Raqi«aO 

A  NOT  REQUREO 


S.  OTHER  TaiLORINQ  pitaen  addibonal  snaan  aa  naoaaiary) 


a  REQUREO 


This  is  a  sample  00  Fonn  2554-1  digital  data  denoted.  Information 
should  be  tailored  to  reflect  program  requirements. 
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Contfsct# 
Page  l  of. 

ATTACHMENT  XX 


00  FORM  2554-1,  BLK  l.e,  OIQITAL  OATA  OEUVERABLES 


2S54-1, 

BLK  1  c 

Oroer 
i _ 1 

PRODUCT  DELIVERABLES  IN  DIGITAL  FORMAT 

(1) 

(  ) 

DRAWING  MASTER  RASTER  OATA 

(2) 

(  ) 

DRAWING  TRIAL  RASTER  OATA 

(3) 

(  ) 

DRAWING  MASTER  PRODUCT  OATA 

W 

(  ) 

DRAWING  TRIAL  PRODUCT  OATA 

(5) 

(  ) 

DRAWING  MASTER  NATIVE  CAIVCAE  OATA 

m 

(  ) 

DRAWING  TRIAL  NATIVE  CAO/CAE  OATA 

(7) 

/  ^ 

ORAVtnNG  MASTER  IGE5  CMVCAE  OATA 

(9) 

(  ) 

DRAWING  TRIAL  IGES  CAIVCAE  OATA 

(9) 

(  ) 

OTHER  •  SEE  NOTE  BELOW 

(10) 

(  ) 

T80 

(11) 

(  ) 

TBO 

(12) 

(  ) 

TBO 

REQUIREMENTS  FOR  PRODUCT  OEUVERABLES 


Qrwwina  Meatar  Raatif  Drti.  OnMina  nwattir  raatv  graphic  lipe  ihal  be  lAW  MiL-R>2B002.  MIL-STD>1840  and 
Mtowing  raqwraewneL  OaM  ahaf  ba  on  a  »«ad(  magnadc  t^M.  Rastar  graphics  ahal  be  type  1  urtlad  raalar  dMa. 
512  X  512  In  aza.  Each  <WNarad  9-track  tap#  ahai  inekide  a  ANSI  labai.  Raalar  image  danaky  ihal  be  200 
PELS/Inch.  Th#  minimum  number  of  PELS  par  Ina  and  minimum  number  of  acaninea  aha!  be  lAW  MIL-R-2S002. 
RaatwimagaohenttfianahalbaPELpadiaf90lnapragtasaiono(270.  Aooaptanoa  of  ttiia  dNa  dam  Mi  be  baasd 
upon:  »etf  ment/oontant  prior  aooapemca  and  vakdafcn  of  drawmgWal  raalar  data,  BLK  l.c(2).  if  ordatad;  and  visual 
a)riiparaavaagraementaiMi>Jraiiwngorigkialaortaproduc>iona.5orderad. 

Oravwno  Trial  Raamr  Dim.  Requiramenta  ahak  be  the  aama  aa  thoae  for  drawing  maalar  raalar  data.  BUO  l.c(l). 
SANS  prior  accaptarwa  of  aalf. 

Drawino  Mavrf  Pmduet  Data.  Oranving  master  product  data  ahal  be  lAW  VHOL  ANSI/IEEE  1076.  EDIF  ElA  545, 
Ml  IPC-O-SSO  and  lha  fatowing  requremants.  Oats  shal  be  on  MIL-STD-ie40  magnefc  tape  tormal  opiieai  ddt. 
CO-ROM,  or  magnedc  disk  wi*ti  a  mukiaAr  agreed  upon  format  Data  Ml  be  organizad  as  one  drawing  par  fla  widt 
muMple  ahaeti  ..jfinittad.  E'"..,,,.  lud  or  unapecHled  by  ttw  appropriala  standards  or  specMcalons  iVOHL 
IPC,  etc.)  data  banafar  intagrily  of  the  product  information  dalvarad  under  the  contact  Formal 

version  '(X)*  shal  be  used.  Acoaptanoe  of  this  data  itam  shal  be  based  uporc  self  meritteootatrt  prior  acceptance 
and  valdalcn  of  drawing  tW  product  data,  BLK  l.c(4).  if  ordered;  and  visual  oomparalve  agreement  wlh  drawing 
origirwia  or  reproductians,  if  ordered.  VaUadon  hare  means  delarminalion  of  acceptable  tansfer  and  translation  of 
data  tom  the  oontractor's  CAO/CAE  system  to  the  (add  appiicabie  intarfacing  system) . 

NOTE:  THIS  IS  A  SAMPLE  ATTACHMENT.  INFORMATION  SHOULD  BE  TAILORED  TO  REFLECT  PROGRAM 
REQUIREMENTS.  SEE  TECHNICAL  MANUALS  SECTION  OF  THE  DESKTOP  GUIDE  FOR  ’COMPOUND 
DOCUMENTS’  (SPECIFICATIONS.  SOFTWARE,  DOCUMENTATION.  USTS,  ETC.). _ 


FIGURE  12.  Sample  Contract  Attachment  On  "DO  Form  2554-1,  BLK  l.c, 

Digital  Data  Deliverables" 
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Contract# _ 

Pag«2of _ 

ATTACHIIENr  XX  (CONT.) 

REQUIREMENTS  FOR  PRODUCT  OEUVERABLES  (CONT.) 

(4)  Qwiiiirw  Triii  Preduel  Qiti.  R*MreriMnli  #wl  ba  ««»  ••  iwra  to  Orrareg  ma-w  preAjet  date.  BLK  i.e(3». 
SANS  poor  accaptwioa  at  aaV. 

(5)  Drareno  Ma^  Ntore  CATVCAg  Oiaaiira  m-to  nto*  (>OCAE  dtoi  dial  ba  aa  tttore.  Thadatafla 

tomal  ahM  ba  dalwarad  on  a  Made  QIC  tra*.  CO-mMI  or  nM^wie  dbk.  oompatUa  wto _ (inaart  vandor 

product  luana).  CAOACAE  ayaton  madta  dial  ba  daadjf  itoaiad  to  daacAa  dw  madta  tomat  rnadud.  oontoit  and 
madte  danaily.  Oda  ahal  ba  oiganizad  aa  ona  dmaing  par  Ra  wdh  muMpla  diaata  pamiMadL  OaiB  tomat  dial  ba 
eomptoMa  wdi  __(inaart  vandor  appfcadon  paetaga  nama.  vaidon  mantoai)  tomat  udng  dia  natoa  bimy  tomal 

aupportodbydia _ (Inaart  vandor  product  namalCAOairitBm.  AljntomadonniBaaaanrtoopanandnianipilaii 

dw  data  flaa.  indudng:  Birariaa.  logicat  tiama  Jalddoni.  and  odiar  auppodng  Raa  dial  ba  dM  mad  vddi  dtaabig 
flaa  Non  vandor-aupportad  \Mldaa*  (l-a..  aottwaia  produd)  ahal  not  adad  dw  dda  bandar  Magrty  of  dw  produd 
intomadon  dalvarad  undar  dw  oonbad  Aocaptanoa  of  dda  dda  iton  dial  ba  baaad  upon:  aad  iwaridoontant  prior 
aooaptanoa  and  valdalon  ct  draaing  bid  nadva  CAQCAE  data.  BLK  1.c(R,  tf  ordarad;  and  daud  oowparatoa 
a^aamant  with  drawing  originala  or  rapredudiona.  if  onlarad.  VaUalon  hara  maana  datawiinadon  of  aonaptabla 
banato  and  bandadon  of  data  from  dia  oonbador's  CAOfCAE  ayaton  to  dia  (add  appicabla  Inlarlacing 
Mton). 

(6)  Oravrino  Trial  Nalva  CAtyroF  n«««  Raqubamanta  dial  ba  dw  anma  as  dwaa  to  drawing  maaid  ndba  CACVCAE 
data,  BLK  t.c(S),  SANS  prior  aooaptanoa  of  aad. 

(7)  Drwwino  Maatif  'Vi  Owring  madar  IGES  CAD/CAE  data  ahal  ba  aa  Wtowa.  Data  dwi  ba 

dalvarad  on  a»badr  ttpa.  QIC  tapa.  or  wagnadc  ddk.  Data  ahal  ba  orgarnad  aa  ana  drawing  par  Ra  wRi  muMpio 
ahaata  parmnad.  MIL-O-2a000  daihad  antHaa  are  mandatory.  Enddaa  not  My  auppotid  or  aufwortad  by  a  aubaal 
of  MiL-0-28000  to  boat  match  dw  oonbaetor'a  CAO  faatiaaa,  dwI  ba  idandlad  by  dw  oonbactor.  Unaupportad  or 
unapaoWadVotuntaar^andlaa  ahal  not  adaetdwdWB  banato  Intagrly  of  dw  product  Intomadon  dalvarad  undar  "a 
oonbacL  Data  product  flaa  dial  ba  writon  in  ASOI  tom.  Aooaptanoa  of  dda  dda  iton  dwi  ba  baaad  upon;  aad 
maritfaontant  prior  aooaptanoa  and  vdMadon  of  drawing  Wai  KSES  CADfCAE  data.  BLK  1.c(8).  if  ordarad;  and  waud 
oomparadva  agraamant  wRi  draaving  origfcwia  or  raproduedona,  if  ontoad.  VdUadon  hara  maana  datomliadon  of 
oocaptabla  banato  wd  bandadon  of  data  tom  dw  oonbaetor'a  CAO/CAE  ayatom  to  dw  (add  appGcabia 
intar  facing  ayatam). 

(8)  Drawinn  Trial  IGES  CAIVCAE  Data.  Raquiramanta  dwi  ba  aanw  aa  dwaa  to  drawing  maator  IGES  CAOICAE  dobc 
BLK  1.c<7).  SANS  prior  acoaptanca  of  aalt. 

(9)  Odwr 

(10)  TBO 

(11)  TBO 

(12)  TBO 

THIS  IS  A  SAMPLE  ATTACHMENT.  INFORMATION  SHOULD  BE 
TAILORED  TO  REFLECT  PROGRAM  REQUIREMENTS. 

FIGURE  12  (cont.).  Sample  Contract  Attachment  On  *DD  Form  2554-1,  BLK  1.c, 

Digital  Data  Deliverables” 


Contract# _ 

Page  1  of  2 

ATTACHMENT  XX 

DISTRIBLmON  STATEMENT  ON  TECHNICAL  CXXJUMENTS 

T>^«  pwpoM  at  thi*  oonvact  Mfetwnant  is  to  MMUtoh  proosdurss  tor  mertong  tochnteai  documsnts,  including  produOton, 
snginesring  ,  srto  logisilcs  infomMtton,  to  dsnoto  tos  sidMit  to  <«tiich  toey  are  etotoHs  tor  dtoeibutian  retoeae,  and 
disseminalton  wilteut  eddMonal  approvals  or  autwrizattons. 

OiaMwIton  covers  al  artgineering  drerwnga.  standards,  spocMeattans,  todwical  manuals,  bluaptinta,  draMngs,  plana, 
inaeucdona,  computar  aaAware  and  documanMton,  arto  otoar  todwical  intonwaHon  ttial  can  be  uaed  or  be  adaptod  tor  uae  to 
design,  sn^neer. produce manu<aaura,operaaa,fapair.ovedw Lor feproduoe any matoiiy  or speoe  aquipinant or todwntogy 
ooncemmg  such  equipmant 

The  diabtoutton  ataamerS  maridnga  shat  be  mandatory  tor  al  tochnieai  documanta,  iiKludtog  such  intotmal  documents  as 
worldng  papers,  mamotsnda,  arxl  prelminary  reports  if  ttwsa  documartts  ate  not  alraady  in  toe  pubic  domain  atto  H  toey  am 
Gkely  to  be  dbaammaasd  outside  of  toe  Ospanmont  of  Oetonsa. 

The  distobubon  statomant  shat  ba  dtoplayad  conspicuously  on  tochnieai  documanta  so  as  to  ba  rooognizsd  leadiy  be 
recipianta. 

Tha  tolloiHlng  shai  apply  tor  standard  writtan  or  printsd  matarlal: 

1.  The  tiabitiutton  alatbmant  shai  appaar  on  each  trortt  cover.  tWa  page  and  DO  Form  1473,  'Rapott  Documantalton  Page.* 

2.  When  practtcaWe.  toe  abstract  of  toe  document,  toe  DO  Form  1473  and  btoiographic  dtations  shol  be  writton  in  such  a 
way  that  toa  ititarmabon  wil  not  ba  subjact  to  disbtouion  statomant  B,  0,  E  or  F. 

If  the  technical  intormatton  is  not  prepared  in  toa  torm  of  an  ordtoaiy  document  and  does  not  have  a  oovsr  or  Me  page  (such 
as  forms  and  charts),  toe  applicable  dstrifautton  statomant  shal  be  stamped,  printod,  wiWan,  or  aflbied  by  otoar  means  in  a 
ffwspwmwft  poartten 

I 

I 

A  disbibution  statomant  marking  is  distinct  from  and  in  addtion  to  a  security  dasaMcation  marking. 

THIS  IS  A  SAMPLE  ATTACHMENT.  INFORMATION  SHOULD  BE 
TAILORED  TO  REFLECT  PROGRAM  REQUIREMENTS. 


FIGURE  13.  Sample  Contract  Attachment  for  Distribution  Statements 
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Contract  # _ 

Paga2of2 


ATTACHMENT  XX 

OISTRIBUnON  STATEME?>4T  OERNITIONS 
jJtaWbullonStalatnant  A  ApproMd  lor  public  naia«ar.  dialribulion  is  unimilid. 

DIaWhmhn  Saamont  B.  OaBtedlan  arturiaM  a  US  Gowanmanl  igaKai  ordy,  Coraaclor  Poifomatto*  fi  ill  aim  tndlv 
AdmiiiiaaKa  or  Opaalonil  Uao;  13  Noiianbor  1966.  Otar  aquoaa  tor  twa  doownt  aal  bo  roamd  a  ia  Naai  Air 
Syaams  Comnand  (PMA-242). 

j 

□ladlbuiap  saaiw^  n  Oadauion  aiiartad  a  ia  OoO  aid  US  OoO  confcari  otiy;  CtWca  Todiaagy;  l3No>anbor 
1968.  Oiarroquoanlal  bo  aanid  a  iaNaal  Air  Sytawa  Comnand  (PIIA-243. 

DIabIbmkin  saanumr  P  Oaabuian  outariad  a  OoO  Componords  eiiy;  OWcoi  Todwaagy  and  Sotaao  Oocumonatan; 
13Nov«mbar19a6.  Oiar foquooaartiio docunantahal bo roarrod a »aNi»al Air S/aomo Comnand  (PMA  242). 

aaribuian  saitMnr  F.  Furtar  dooaulan  only  os  ^oead  by  NomI  Air  Syoamo  Command  (PMA>242)  a  Nghar  OoO 
autariy;  13  Nowambar  1966. 

Al  aehnioal  documana  tha  ara  daarminad  a  oonain  aaart-cciiaoiad  adaioal  data  dal  ba  maifcad  VIARNIN6>This 
docurrard  oonaina  adaical  daa  whoao  OMport  ia  raabicad  by  da  Arms  Baat  Conbd  Act  (TiH*  22,  U.S.C.  SEC  2751.  at 
aaq.)ordaEiaortAdniniairaionAdo<1979.  as  anandod,  TWa  SO.  U.S.C.,  App  2401  at  saq.  Vtaaiaia  ol  daoa  aiaort 
araaubiada-aaaraoiminatponaHaa.  Oiiaamaaa  a  acoardanca  wall  pwddonsotDoOaradNa  5230.25. * 

For  daaaMad  docunards,  alow  da  praooduras  a  OoO  9200.00-M,  InduabW  Sacuribi  Manual,  Chapar  5,  Saclon  5-706  or 
Oo05200.1-R  Intormaion  Sacurity  ftogram  Raqulaflon,  Chaptar  DC 

THIS  S  A  SAMPLE  ATTACHMENT.  MPORMATION  SHOULD  BE 
TAILORED  TO  REFLECT  PROGRAM  REQUIREMENTS. 


FIGURE  13  (cont).  Sample  Contract  Attachment  for  Distribution  Statements 
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DICirAI.LBSB(0; 


V.VKWONLY  ■<EXnWCT/P(K)CeSSmi«NSKRM  U « UPOATCAMMTMN  C  •  OOMUBfr/ANNOTATl  A.APPtlOVC 


la^  v-4  ■  vamv  OILY,  POUR  Twes 


FIGURE  14.  Sample  Attachment  for  DO  Form  1423-1,  BIk  14,  "Distribution" 
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4.4.9. 1  Cost 


Once  product  data  files  has  been  selected  as  the  data  delivery  format,  the  cost  of 
acquiring  this  data  can  be  calculated.  A  chart  (see  figure  15)  has  been  developed  to 
assist  the  Acquisition  Manager  in  estimating  this  cost.  This  15-step  process  includes 
cost  estimates  for  a  vanety  of  data  delivery  options.  The  Acquisition  Manager  should 
skip  over  any  of  the  data  auiivery  options  not  required  by  the  defense  system  program. 
If  paper  deliverables  are  not  required  for  verification,  as  in  the  early  stages  of  the 
defense  system's  life  cycle,  they  may  be  left  out  of  the  cost  estimate  by  skipping  step  8. 

Note:  This  chart  will  provide  an  approximation  of  costs  associated  with  these  data 
deliverables.  Specific  program  requirements,  especially  labor  rates,  may  vary  from 
those  presented  here  and  may  be  substituted  for  the  rates  shown. 

4.4.9.2  CDRLs 

To  invoke  these  data  deliverable  options,  specific  CORLs  (see  figures  10  through  14) 
have  been  developed  to  be  used  as  examples.  The  infonnation  contained  in  these 
contract  vehicles  should  be  tailored  to  meet  the  requirements  of  the  spedfic  defense 
system  program.  The  CORL(s)  must  include  language  that  specifies  exactly  how  data 
will  be  delivered  (including  media,  format,  and  content)  under  the  contract.  CALS 
standards  should  be  invoked  whenever  possible. 

4.4.10  Native  CAO/CAE  Data  RIe  Delivery  Option 

CAO/CAE  data  files  in  native  format  (see  figure  8)  consist  of  a  variety  of  data  delivery 
options  irxsiuding  native  CAO  data  files,  text  data  files,  and  POES.  PDES,  which  has 
been  included  in  figure  8,  will  not  be  included  in  the  cost  estimate  since  this  data  is 
currently  under  development  and  is  not  "mature*  enough  to  be  considered  as  a  delivery 
option  at  this  time.  CAO  data  files  and  text  data  files  are  described  in  4. 1.1. 2.1  and 

4. 1.1. 2.2  respectively,  and  a  discussion  of  intelligent  data  is  provided  in  Appendix  B. 
These  data  deliverables  provide  all  the  data  uses  described  in  MIL-HD6K-59  including 
view,  archive,  comment/annotate,  update/maintain,  and  extrad/process/transform. 
Suggested  delivery  media  options  include:  (1)  Optical  disk,  (2)  magnetic  disk,  or  (3)  9- 
track  magnetic  tape,  all  in  accordance  with  MIL-STD-1840.  Paper  documentation  may 
be  requested  in  addition  to  the  digital  data  deliverables  but  only  for  verification  of  the 
digital  data 

4.4.10.1  Cost 

Once  CAD/CAE  data  files  in  native  format  has  been  selected  as  the  data  delivery 
format,  the  cost  of  acquiring  this  data  can  be  calculated.  A  chart  (see  figure  16)  has 
been  developed  to  assist  the  Acquisition  Manager  in  estimating  this  cost.  This  seven- 
step  process  includes  cost  estimates  for  both  CAO/CAE  data  files  and  paper  data 
delivery  options.  Tne  Acquisition  Manager  should  skip  over  any  of  the  data  delivery 
options  not  required  by  the  defense  system  program.  If  paper  deliverables  are  not 
required  for  verification,  as  in  the  early  stages  of  the  defense  system's  life  cycle,  they 
may  be  left  out  of  the  cost  estimate  by  skipping  step  4. 
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MlinMiBdoosi 

ip«rdiliv«rablM 


NOTE:  COST  ESTIMATES  WERE  DERIVED 
FROM  THE  AVERAGE  COST  FOUND  FROM 
A  STUDY  PERFORMED  BY  THE  CALS  RIC. 
COST  ESTIMATES  MAY  VARY  AND  SHOULD 
BE  TAILORED  FOR  MORE  ACCURACY. 


FIGURE  16.  Cost  Estimate  -  Native  CAD/CAE  Data  Hies 


Note:  This  chart  will  provide  an  approximation  of  costs  associated  with  these  data 
deliverables.  Specific  program  requirements,  especially  labor  rates,  may  vary  from 
those  presented  here  and  may  be  substituted  for  the  rates  shown. 

4.4.10,2  CORLs 

To  invoke  these  deliverable  options,  specific  CORLs  (see  figures  10  through  14)  have 
been  developed  to  be  used  as  examples.  The  information  contained  in  these  contract 
vehicles  should  be  tailored  to  meet  the  requirements  of  the  specific  defense  system 
program.  The  CORL(s)  must  include  language  that  specifies  exactiv  how  data  will  be 
delivered  (including  merfia,  format,  and  content)  under  the  contract  CALS  standards 
should  be  invoked  whenever  possible. 

4.4.11  Product  Data  RIe  Delivery  Option  (IGES  Format) 

Product  data  files  in  IGES  format  (see  figure  8)  consist  of  a  vanety  of  data  delivery 
options  including  IGES  files,  text  data  files,  and  POES.  POES,  which  is  included  in 
figure  8,  will  not  be  included  in  the  cost  estimate  since  this  data  is  currerrtly  under 
developmerrt  and  is  not  "mature*  enough  to  be  considered  as  a  delivery  option  at  this 
time.  IGES  files  are  included  in  the  discussion  of  CAO  data  files  in  4. 1.1. 2.1,  and  text 
data  files  are  described  in  4. 1.1. 2.2.  A  discussion  of  "Intelligent*  data  is  provided  in 
Appendix  B.  These  data  deliverables  provide  all  the  data  uses  described  in  MIL-HDBK* 
59  including  view,  archive,  comment/annotate,  update/maintain,  and  extract/process/ 
transform.  Suggested  delivery  media  options  include:  (1)  Optical  disk,  (2)  magnetic 
disk,  or  (3)  9-track  magnetic  tape,  all  in  accordance  with  MiL-STD-1840.  Paper 
documentation  may  be  requested  in  addition  to  the  digital  data  deliverables  out  only  for 
verification  of  the  digital  data 

4.4.11.1  Cost 

Once  product  data  files  in  IGES  format  has  been  selected  as  the  data  delivery  format, 
the  cost  of  acquiring  this  data  can  be  calculated.  A  chart  (see  figure  17)  has  been 
developed  to  assist  the  Acquisition  Manager  in  estimating  this  cost.  This  seven-step 
process  includes  cost  estimates  for  both  IGES  files  and  paper  data  delivery  options. 
The  Acquisition  Manager  should  skip  over  any  of  the  data  delivery  options  not  required 
by  the  defense  system  program.  If  paper  deliverables  are  not  required  for  verification 
as  in  the  early  stages  of  the  defense  system's  life  cycle,  they  may  be  left  out  of  the  cost 
estimate  by  skipping  step  4. 

Note:  This  chart  will  provide  an  approximation  of  costs  associated  with  these  data 
deliverables.  Specific  program  requirements,  especially  labor  rates,  may  vary  from 
those  presented  here  and  may  be  substituted  for  foe  rates  shown. 

4.4.11.2  CDRLs 

To  invoke  this  data  deliverable  option,  specific  CORLs  (see  figures  10  through  14)  have 
been  developed  to  be  used  as  examples.  The  information  contained  in  the  following 
contract  vehicles  should  be  tailored  to  meet  the  requirements  of  the  specific  defense 
system  program.  The  CDRL(s)  must  include  language  that  specifies  exactiv  how  data 
will  be  delivered  (including  media,  format,  and  content)  under  the  contract.  CALS 
standards  should  be  invoked  whenever  possible. 
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4.4.12  0«iivoiy  Option  Advantagas 


Delivery  of  the  TOP  as  paper,  raster,  vector,  or  processable  data  file  has  tx>th 
advantages  and  disadvarrtages.  Table  1  lists  some  of  these  advantages  and 
disadvantages. 
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COST  ESTIMATES  MAY  VARY  AND  SHOULD 
BE  TAILORED  FOR  MORE  ACCURACY. 


FIGURE  17.  Cost  Estimate  -  Product  Data  Rles  -  IGES 


4.5  Contractor  Validation 


The  contractor  should  be  required  to  validate  that  the  TOP  and  associated  elements 
conform  to  the  contractual  requirements.  In  those  Instances  where  materiel  has  been 
developed  or  produced,  the  contractor  shall  validate  that  the  TOP  and  associated 
elements  accurately  depict  the  materiel  developed  or  produced  under  the  contract 
Use  of  the  TOP  in  producing,  inspecting,  and  testing  satisfactory  materiel  is  considered 
acceptable  evidence  that  the  validation  requirement  has  been  met  When  specified  in 
the  contract  or  purchase  order,  the  contractor's  validation  shall  be  documented  in  a 
TOP  validation  report 

4.5.1  Validation  by  Contractor  Physical  Configuration  AudH  (PCA)  or  Verification 
Reviews 

The  Govemmern  may  require  the  contractor  to  validate  the  TOP  through  PCAs, 
configuration  itein  verification  reviews  (CiVRs),  or  by  other  methods  through  specific 
work  tasks  in  the  statement  of  work  of  the  contract  or  purchase  order.  Unless  such 
tasks  are  included  in  the  contract  or  purchase  order,  the  method  of  validation  shall 
remain  the  contractor's  option. 

4.5.2  TOP  Validation  Report 

A  TOP  validation  report  is  used  by  the  Government  to  review  the  procedures  and 
evaluate  the  results  of  the  contractor's  validation  of  the  TOP  as  conforming  to  the  data 
requirements  in  the  contract  or  purchase  omier. 

4.6  Government  Verification 

The  acceptance  of  CALS  digital  data  products,  either  delivered  on  physical  media  or  by 
CITiS,  is  different  in  several  ways  from  the  acceptance  of  comparable  paper  data 
products.  The  following  paragraphs  provide  details  on  the  acceptance  of  digital  data 
products  and  information  services. 

4.6.1  Digital  Data  Product  Acceptance 

The  unique  aspect  of  CALS  digital  data  deliverables  is  that  they  will  be  subject  to 
inspec  onandar  '  p  ''  on  several  levels.  The  lowest  level  of  acceptance  is  the  dau 
conte'^^  at.  The  acceptance  process  at  this  level  is  identical  to  acceptance  of 

the  data  product  provided  on  paper.  This  level  of  acceptance  will  be  accomplished  by 
viewing  the  data  either  through  use  of  a  computer  video  screen  or  by  viewing  a  paper 
printout  of  the  data  product. 

The  next  level  of  acceptance  is  adherence  to  the  specified  CALS  data  exchange 
format.  This  will  usually  be  compliant  with  the  CALS  standardization  documents  or 
other  national  or  international  data  exchange  standards.  This  level  of  acceptance  may 
be  aided  by  automated  tools  obtained,  if  available,  from  the  CALS  Test  Network  (CTN) 
or  each  service-component  CALS  office. 
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The  next  level  of  acceptance  is  applied  to  the  MIL-STD-1840  digital  data  format  if  it  has 
been  specified.  Again,  automated  tools  may  be  used  to  verify  compliance.  Other 
formatting  requirements  that  may  be  subject  to  irispection  and  acceptance  include  the 
X12  EDI  format  if  it  has  been  specified  (see  3.7.1). 

Rnaliy,  the  physical  media  may  have  acceptance  chteha  to  be  applied.  This  level  of 
accefirtance  will  not  be  used  if  data  has  been  formally  delivered  by  the  CITIS.  The 
means  of  inspection  to  be  used  should  be  provided  to  foe  contractor  as  soon  as  these 
means  have  been  determined.  Any  or  all  levels  of  acceptance  may  be  performed  at 
foe  contractor's  facility  or  at  a  Government  fadiity.  as  required,  in  addition  to  digital 
data  acceptance,  CITIS  requires  that  additional  acceptance  requirements  be  applied. 

4.6.2  CmS  Acceptance 

Acceptance  of  foe  service  and  foe  t..<ITIS  Contract  Line  Item  Number  (CLIN)i  if  utilized, 
is  a  verification  that  foe  contractor  has  provided  foe  service  as  specified.  The  CITIS 
functional  requiremerrts  are  defined  by  MIL-STD-CITIS  draft  (MIL-STD-974)  and  the 
particular  statement  of  work.  A  checklist  of  CITIS  functional  requirements  may  be 
prepared  to  assist  in  tracking  contractor  compliance.  These  functional  requirements 
may  include  service  availability,  maintenance  response,  provision  for  core  information 
functiorts,  provision  for  value-added  information  functions,  and  foe  like. 

Assurances  of  adequate  acceptance  testing  for  CITIS  should  be  obtained  via  contractor 
demonstration  of  foe  service.  The  test  should  include  demonstration  of  functional 
capabilities  and  verification  that  foe  CITIS  vmII  handle  foe  data  required  without 
alteration  of  foe  data  product.  Such  a  test  is  not  required  for  each  delivery  but  may  be 
rerun  if  m^or  maintenance  has  been  accomplished  or  if  foe  sending  or  receiving 
systems  have  been  changed  enough  to  warrant  an  additional  test.  If  specific  test  data 
are  deemed  necessary  for  adequate  testing  of  a  CITIS,  that  test  data  should  be 
provided  and  results  reviewed  on-site  at  a  customer  facility.  On-line  access  service 
should  be  accepted  when  it  is  demonstrated  that  a  person  with  proper  authorization 
can  perform  foe  contractually  required  core  and  value-added  functions  from  a  terminal 
or  workstation  at  foe  customer's  facility  or  as  otherwise  agreed. 

Electronic  data  transfer  service  acceptance  should  occur  when  a  single  instance  of 
transfer  of  foe  specific  deliverable  type  can  be  achieved  includinc  successful  download 
of  data  into  foe  customer's  system  when  contractually  required.  This  data  may  be  real 
product  data  or  test  data,  as  appropriate. 

4.6.3  CALSIP  Acceptance 

The  original  contracts  baseline  requirements  for  CALS-compliant  product(s)  are  subject 
to  change  and  redefinition,  by  mutual  agreement,  throughout  foe  duration  of  the 
contract.  The  Government  verifies  and  controls,  in  part,  foe  adequacy  of  foe  CALS 
product  change  and  redefinition  process  via  foe  approval  of  foe  original  and  revision(s) 
of  the  CALSIP  along  with  the  final  acceptance  of  foe  CALSIP  at  contract  completion. 
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FOREWORD 


Purpose 

The  Navy  Computer-aided  Acquisition  and  Logistic  Support  (CALS) 
Acquisition/Implementation  Sub-Group  has  charged  the  CALS  Resource  and 
Implementation  Cooperative  (RIQ  with  developing  acquisition  guidance  for  each  of  the 
three  process  architectures  defined  in  the  OefMutment  of  the  Navy  CALS 

Architecture/Implementation  Plan.  This  document  is  the  result  of  an  exhaustive  search 
and  distillation  of  information  pertinent  to  applying  CALS  to  the  creation,  management, 
and  use  of  Technical  Manuals  (TMs).  The  intended  audience  of  this  document  is  the 
Acquisition  management  team  that  may  consist  of  Navy/Marine  Corps  Acquisition 
Managers,  TM  Managers,  project  engineers,  and  project  logisticians.  This  document 
lends  itself  to  irtcorporation  into  specific  Naval  Forces  System  Command  and  Marine 
Corps  program  manager  guides  for  applying  CALS  to  defense  system  procurements. 

Scope 

The  three  process  architectures  described  in  the  Navy  CALS 

Architecture/Implementation  Plan  are: 

•  Engineering  Drawings 

•  Technical  Manuals 

•  Logistic  Support  Analysis  Record  (LSAR). 

This  revision  has  been  expanded  to  include: 

•  Process  Flow 

•  Proposal  Evaluation  Criteria 

•  Discussion  on  Contractor  Integrated  Technical  Information  Service  (CITIS) 

•  Decision  Oriented  Templates. 

Overview 

Section  3.0,  General  Considerations,  provides  topics  of  consideration  that  must  be 
addressed  by  the  acquisition  management  team  pertaining  to  the  application  of  CALS 
initiatives  to  TMs.  This  section  covers  the  following  considerations: 

•  TM  Decision  and  Responsibility 

•  Identify/Establish  the  TM  Requirement 

•  Identify  TM  User's  Infrastructure 

•  TMs  in  a  CALS  Environment 

•  Life  Cycle  Considerations 

•  Contract  Language. 

Section  4.0,  Specific  Considerations,  uses  these  topics  as  a  basis  to  discuss  specific 
transfer  media  and  digital  data  format  considerations  through  decision  templates  that 
will  assist  the  acquisition  management  team  in  determining  which  of  these  will  satisfy 
the  defense  system  program's  TM  requirements.  Sample  contract  language  to  help 
develop  CALS-related  contract  documents  and  a  discussion  of  validation  and 
verification  issues  are  also  included. 
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1.0  INTRODUCTION 


Computer-aided  Acquisition  and  Logistic  Support  (CALS)  is  a  Department  of  Defense 
(DoD)  and  industry  strategy  intended  to  en^le  more  effective  generation,  exchange, 
management,  and  use  of  digital  data  supporting  defense  systems  and  equipment. 
Technical  Manuals  (TMs)  are  publications  that  contain  instructions  for  the  installation, 
operation,  maintenance,  and  support  of  defense  systems,  defense  system 
components,  and  support  equipment.  Using  CALS  standards  to  define  the  digital 
environment  for  the  creation,  management,  and  use  of  TMs  will  provide  the  method  for 
transitioning  from  paper- intensive  defense  system  acquisition  and  support  processes  to 
automated  and  integrated  digital  processes. 

It  should  be  noted  that  the  application  of  digital  technologies  to  Navy  processes  should 
be  seen  as  a  way  to  improve  and  streamline  these  processes  by  providing  better 
methods  of  creating,  managing,  and  using  data,  not  as  a  method  of  replacing  existing 
business  practices. 

1.1  Scope 

Considerations  that  must  be  addressed  when  the  acquisition  management  team  is 
acquiring  TMs  in  digital  format  include  who  will  use  the  data  and  what  infrastructure  will 
they  need  to  use  it.  Three  levels  of  activity  (see  figure  1)  exist,  and  all  must  have  the 
ability  to  access  and  apply  the  digital  data 

The  first  activity  is  the  acquisition  program  office  itself.  It  will  be  impossible  possible  to 
manage  a  .program  adequately  if  the  TM  agent  does  not  have  the  capability  to  review 
and  comment  on  the  TM  that  is  being  delivered.  The  acquisition  management  team 
must  insure  that  appropriate  hardware  and  software  are  in  place  to  review  the  data 
before  digital  data  is  ordered  and  delivered. 

The  second  level  of  activity  that  must  be  considered  is  the  specific  Navy  infrastructure 
program  that  will  manage  and  store  the  digital  data  once  it's  created.  The  data 
delivered  must  be  compatible  with  the  existing  Navy  infrastructure  in  place  or  being 
developed.  If  changes  to  the  Navy  infrastructure  are  required,  they  must  be  fully 
justified  and  coordinated  with  personnel  responsible  for  the  configuration  control  of  the 
Navy  infrastructure  system. 

The  *inal  level  ar*i-."*'/  that  must  be  considered  is  the  end  user.  It  does  the  end  user 
no  yonw  to  g,-neraic;  eind  make  available  digital  data  that  they  are  incapable  of  using. 
The  v.-w,w.ou.jn  management  team  cannot  assume  the  systems  exist  and  will  be  used. 
The  specific  environmerrt  must  be  determined.  Questions  must  be  asked.  What 
systems  are  available  in  the  field?  For  a  specific  user,  what  data  media  and  formats 
are  compatible  with  what  they  already  have  or  are  planning  to  get?  How  will  they 
acquire  the  new  equipment  and  software  they  need  if  existing  systems  are  inadequate? 
How  will  these  new  systems  be  supported?  Who  will  pay  for  these  new  systems?  The 
answers  to  these  and  similar  questions  v/ill  provide  a  comprehensive  plan  for 
implementing  and  using  the  digital  data  that  is  acquired.  The  answers  depend  on  the 
specific  users  in  the  specific  program. 

It  is  recognized  that  each  defense  system  program  is  unique  with  individual  constraunts 
and  access  to  a  distinct  set  of  infrastructure  systems.  This  document  is  intended  to 
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provide  the  acquisition  management  team  with  an  overview  of  Navy  business  practices 
for  the  creation,  management,  and  use  of  TMs  in  a  CALS  environment  yet  maintain 
flexibility  for  innovative  approaches.  Specific  implementation  of  this  process  may  be 
further  tailored  with  guidance  set  forth  by  each  Naval  Forces  System  Command. 


FIGURE  1 .  The  Three  Levels  of  Data  Activity 


1.2  Purpose 

The  planning  processes  for  the  creation,  management,  and  use  of  TMs  in  a  CALS 
environment  needs  to  take  advantage  of  the  capabilities  provic'ed  by  the  automation 
and  inte'jration  of  information  systems.  Various  format  options,  are  available  for  the 
delivery  or  i  Ms  that  are  needed  to  define  and  support  a  defense  system.  The  intent  of 
this  document  is  to: 

•  Provide  an  overview  of  the  TM  acquisition  process 

•  Provide  a  step-by-step  process  for  each  TM  decision 

•  Describe  delivery  options  available  for  TM  acquisition 

•  Provide  a  method  to  determine  the  cost  associated  with  each  option 

•  Provide  guidance  for  specific  contract  language  required  to  support  the  options 
selected 

•  Discuss  contractor  validation  and  Government  verification  procedures. 
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This  document  contains  ordering  information  for  the  deliverable  media  and  digital 
format  for  TMs.  The  guidance  in  this  document  addresses  the  delivery  consideration  of 
TMs  as  defined  in  MIL-HDBK-59.  The  Contract  Data  Requiremertts  List  (CDRL) 
guidance  contained  in  this  document  applies  to  all  types  of  TMs. 
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2.0  REFERENCES 

2.1  Acronyms 

• 

A  complete  list  of  acronyms  used  throughout  the  Desktop  Guide  is  in  Appendix  A.  The 
following  acronyms  are  used  in  this  section  of  the  guide. 

ADMAPS 

Automated  Document  Management  and  Publishing  System 

ASCII 

American  Standards  Code  for  Information  Interchange 

ATIS 

Advanced  Technical  Information  System 

CALS 

Computer-aided  Acquisition  and  Logistics  System 

CALS  RIC 

CALS  Resource  and  Implementation  Cooperative 

CALSIP 

CALS  Implemernation  Plan 

CDRL 

Contract  Data  Requirements  List 

CGM 

Computer  Graphics  Metafile 

CITIS 

Contractor  Integrated  Technical  Information  Service 

CLIN 

Contract  Lii  le  Item  Number 

CTN 

CALS  Test  Network 

DoD 

Department  of  Defense 

DoOl 

DoD  Instruction 

DTD 

Document  Type  Definition 

EDI 

Electronic  Data  Interchange 

FOSI 

Formatting  Output  Specification  Instance 

FRC 

Final  Reproducible  Copy 

GCO 

Government  Concept  of  Operations 

lETM 

Interactive  Bectronic  TM 

• 

IGES 

Initial  Graphics  Exchange  Specification 

ILS 

Integrated  Logistics  Support 

JEDMICS 

Joint  Engineering  Data  Management  and  information  Control  System 

LRU 

Line  Replaceable  Unit 

LSAR 

LSA  Record 

NIFF 

Navy  Image  File  Format 

OS 

Output  Specification 

PC 

Personal  Computer 

PDL 

Page  Description  Language 

SGML 

Standard  Generalized  Markup  Language 

SOW 

Statement  of  Work 

SPAWAR 

Space  &  Navy  Warfare  Systems  Command 

SPDL 

Standard  Page  Description  Language 

TDP 

Technical  Data  Package 

TM 

Technical  Manual 

TMCR 

TM  Contract  Requirement 

TMM 

Technical  Manual  Manager 

TMPODS 

TM  Print-On-Demand  System 

WRA 

Weapon  Replaceable  Assembly 

2.2  Definitions 

Definitions  used  in  this  section  and  throughout  the  Desktop  Guide  are  in  Appendix  A: 

Definitions. 
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• 

2.3  Applicable  Documents 


Documents  referenced  in  this  section  and  throughout  the  Desktop  Guide  are  listed  in 
Appendix  A:  Applicable  Documents. 


3.0  GENERAL  CONSIDERATIONS 


The  development  of  a  CALS  strategy  for  TMs  needs  to  be  carefully  examined  to 
maximize  the  value  for  a  specific  defense  system  program.  Program  attributes  such  as 
technology,  costs,  quantities,  and  schedules  have  a  profound  effect  on  the  deliverable 
requirements  of  TMs.  Therefore,  the  acquisition  management  team  must  consider  the 
life  cycle  of  the  procurement  and  the  Navy  infrastructure  in  place  to  support  the  TMs  for 
their  program. 

TMs  are  any  technical  publication  or  other  form  of  documentation  used  to  install, 
operate,  maintain,  test,  repair,  overhaul,  or  provide  logistic  support  of  ships,  aircraft, 
defense  systems,  or  defense  material.  TM  data  may  be  presented  or  delivered  in  any 
form  including,  but  not  limited  to,  hard  copy,  audio  and  visual  displays,  magnetic  tape, 
discs,  and  other  electronic  devices.  TMs  are  divided  into  three  major  categories; 
Description,  Operation,  and  Maintenance  with  Illustrated  Parts  Breakdown;  Installation 
and  Checkout  Procedures;  and  Technical  Repair  Standards.  The  acquicition  guidance 
provided  in  this  document  will  app'y  to  these  categories. 

The  following  sections  discuss  various  topics  of  consideration  that  must  be  addressed; 

•  TM  Decision  and  Responsibility 

•  Iderrtify/Establish  the  Requirement  for  the  TM 

•  Identifying  the  TM  User's  Infrastructure 

•  TMs  in  a  CALS  Environment 

•  Life  Cycle  Considerations 

•  CDRLs. 

3.1  TM  Decision  and  Responsibility 

The  following  sections  of  this  document  are  devoted  to  the  acquisition  of  TMs  in  a 
digital  environment.  The  purpose  of  the  flow  chart  (see  figure  2}  is  to  lead  the 
acquisition  management  team  through  a  logical  series  of  decisions  and  responsibilities 
associated  with  the  overall  process  of  TM  format  and  delivery  media  selection.  Cost 
comparison  information  and  recommended  CDRL  language  is  also  provided. 

The  flow  chart  also  recommends  who  specifically  is  accountable  for  performing  each 
task  and  function  or  making  a  decision.  In  addition  to  identifying  the  responsible 
agency  or  ^ent  for  » i  tasks,  functions,  or  decisions,  this  chart  also  identifies 
supporting  -  and  their  inputs  as  required. 

NOTE:  Shadowed  task/function  boxes  alert  the  user  of  additional  details  and/or 
decision  flow  charts. 
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FIGURE  2.  TM  Decision  and  Responsibility  Flow  Chart 


3.2  Identify/Establish  the  Requirement  for  the  TM 

The  acquisition  management  team  must  first  identify  the  requirement  to  procure  a  TM. 
This  is  usually  brought  about  through  the  Logistic  Support  Analysis  Record  (LSAR) 
process  and  other  requirements,  such  as  the  need  to  perform  maintenance  on  the 
equipment.  The  LSAR  database  generated  during  the  initial  phases  of  the  defense 
system  program  will  usually  define  the  requirement  for  particular  TMs. 

3.3  Identifying  the  TM  User's  Requirements 

The  acquisition  management  team  must  now  identify  the  intended  TM  user's 
infrastructure.  The  users  include:  Those  involved  in  the  acquisition,  review,  and 
approval;  the  TM  management  infrastructure;  and  the  end  user  (who  may  not  yet 
operate  in  a  digital  environment).  The  acquisition  management  team  should  consider 
the  existing  and  planned  infrastructures  for  both  Government  and  contractor  facilities; 
available  CALS  data  exchange  standards;  and  the  various  digital  data  deliverable 
options  in  terms  of  media,  format,  and  access.  Documentation  of  this  review  will  take 
the  form  of  a  Government  Concept  of  Operations  (GCO).  The  review  will  include; 

•  The  identification  of  current,  near,  and  midterm  infrastructure  plans  for  the 
enterprise 

•  The  ability  for  peer-to-peer  communication 

•  The  throughput  capability  to  support  movement  of  data  electronically  using  the 
installed  telecommunications  infrastmcture 

•  The  personnel  and  their  disciplines  at  all  locations  that  are  members  of  the 
acquisition  management  team 

•  The  digital  data  resources  or  source  data  (libraries  of  historical  data,  standards, 
and  specifications)  available  to  support  program  acquisition  and  logistics 
processes. 

Provisioning  for  end  user  hardware  and  software  requirements  to  support  a  fielded 
defense  system  are  normally  under  the  funding  discretion  of  the  acquisition 
management  team  and  must  be  considered  during  the  CALS  implementation  strategy 
and  planning  process. 

A  more  detailed  guidance  is  provided  in  section  4,  Guide  for  Developing  a  CALS  GCO, 
in  the  "Navy/Marine  Corps  Manager's  Desktop  Guide  for  CALS  Implementation." 

3.3.1  Infrastructure  Development 

Effective  acquisition  of  digital  data  can  be  done  only  with  full  consideration  of  the  ability 
of  Naval  Forces  activities  to  receive,  store,  distribute,  and  use  digital  data  that  complies 
with  the  CALS  standards.  The  acquisition  management  team  must  establish  the  uses 
for  which  the  data  is  required  (see  3.3.2)  and  the  Navy  infrastructure  modernization 
programs  (see  Appendix  C)  available  to  support  this  data.  In  response  to  DoDI  5000.2, 
DoD  components  are  incrementally  upgrading  the  infrastructure  toward  a 
comprehensive  technical  information  management  architecture  through  joint  service 
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programs  like  Joint  Engineering  Data  Management  Information  and  Control  System 
(JEOMICS)  (see  Appendix  C).  The  evolution  of  this  infrastructure  is  a  key  cortsid«’ati(xi 
in  implementing  the  CALS  strategy  on  any  given  acquisition.  Defidenctes  in  the 
Government's  infrastructure  may  require  investments  by  the  acquisition  management 
team  to  implement  the  CALS  strategy  effectively. 

The  availability  of  digital  data  processing  and  telecommunications  technology  and 
approved  standards  for  creation,  storage,  transmission,  data  protection,  and  integrity  of 
data  at  the  time  of  delivery  or  access  are  important  criteria  for  acquisition  dedsions. 
The  current  and  projected  capabilities  of  both  the  contractor  and  Naval  Forces 
compor^nts  must  be  assessed  with  respect  to  program  needs  and  schedules.  The 
GCO  and  CALS  Implementation  Plan  (CALSIP)  counterparts  are  excellent  vehides  for 
making  these  determinations.  The  acquisition  management  team  must  plan  to  access 
or  acquire  digital  data  products. 

The  data  user  infrastructure,  which  is  the  computing  environment  available  to  a 
particular  user,  must  be  considered  when  acquiring  digital  data.  This  environment 
establishes  the  data  processing  capabilities  of  that  user.  The  following  areas  identify  a 
user's  infrastructure: 

•  Hardware:  Determine  the  current  and  planned  hardware  available  to  support 
the  defense  system  program. 

«  Software:  This  is  the  most  critical  element.  Interoperability  will  normally  be 
achieved  through  the  use  of  software.  Again,  determine  both  present  and 
future  software  applications  and  availability. 

•  Networks:  Determine  the  local-  and  wide-area  networking  capabilities  and 
whether  CITIS  will  be  used. 

The  Navy  infrastructure  modernization  programs  specifically  designed  to  aid  in  the 
creation,  management,  and  use  of  TMs  are: 

•  Automated  Document  Management  and  Publishing  System  (ADMAPS) 

•  TM  PuWish-On-Demand  System  (TMPODS) 

•  Advanced  Technical  Information  Support/Interactive  Bectronic  TM  (ATIS/IETM) 

An  overview  of  these  information  management  infrastructure  programs  is  contained  in 
Appendix  C. 

3.3^  Data  Uses 

TMs  are  subject  to  ail  uses  defined  in  MIL-HDBK-59.  The  acquisition  management 
team  will  need  to  identify  the  use  of  the  data  by  all  organizations  involved  in  the 
acquisition  program.  The  acquisition  management  team  must  consider  how  data  will  be 
processed  to  make  good  decisions  on  digital  data  requirements.  The  five  defined 
categories  of  data  processing  typical  of  most  defense  system  programs  are: 
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•  View  only:  The  ability  to  examine  a  data  file  without  the  ability  to  change  it 
This  includes  viewing  selected  portions  of  one  or  several  documents  as  well  as 
side-by-side  comparisons  of  documents.  This  activity  is  an  excellent  candidate 
for  applying  the  Contractor  Integrated  Technical  Information  Service  (CITIS) 
concept. 

•  Comment/Annotat*'  The  ability  to  evaluate  and  highlight  for  future  refererKe  or 
to  make  annotations,  approvals,  and  comments  without  the  ability  to  change  the 
original  file.  Annotations  are  associated  with  a  specific  item  or  location  within  a 
document  such  that  the  annotations  are  displayed  whenever  that  point  or  area 
of  the  document  is  displayed.  Core  CITIS  functions  (approve,  comment,  view) 
are  intended  to  provide  this  capability  and  should  be  given  consideration. 

•  Update/Maintain:  The  ability  to  change  data,  either  directly  or  through 
controlling  software,  in  the  active  files  on  the  host  computer. 

•  Extract/Process/Transfor.n:  The  ability  to  extract  and  modify  the  format, 
composition,  and  structure  of  the  data  into  another  usable  form. 

•  Archive:  The  placing  of  data  into  a  repository  to  preserve  it  for  future  use. 

3.4  TMs  in  the  CALS  Environment 

The  acquisition  management  team  should  be  aware  that  it  is  possible  to  acquire  TMs  in 
a  variety  of  forms  depending  upon  the  needs  of  the  users.  Maintenance  manuals  and 
the  like  may  be  procured  as  Interactive  Electronic  TMs  (lETMs).  The  user  would  be  the 
technician  whose  main  concern  is  finding  the  desired  maintenance-related  information 
quickly  and  easily  without  being  burdened  in  the  field  with  the  entire  maintenance 
manual.  On  the  other  hand,  description,  operation,  and  installation  and  checkout 
manuals  may  be  procured  best  in  raster  or  Page  Description  Language  (PDL)  since 
these  manuals  are  not  used  as  often.  Obviously,  it  is  better  to  leave  these  dedsions  up 
to  the  individual  program  office  since  each  defense  system  program  is  unique  in  its 
requirements. 

Primary  considerations  for  the  acquisition  management  team  to  address  when  applying 
CALS  to  the  creation,  management,  and  use  of  TMs  is  the  media,  format,  and  conterrt 
of  TM  data  deliverables  and  their  respective  end  users. 

Paper,  microfiche,  and  microfilm  have  been  included  in  this  discussion  of  CALS 
because  much  of  the  Navy's  TM  inventory  is  still  available  on  these  media  Navy  CALS 
initiatives  (see  Appendix  C,  Navy  Infrastructure  Modernization  Programs)  are  being 
developed  to  reduce  or  eliminate  the  need  for  these  forms  of  media  in  the  future.  The 
benefits  associated  with  using  digital  data  far  exceed  what  is  being  discussed  in  this 
paper.  For  TMs  seme  benefits  of  digital  data  include:  (1)  Improving  the  handling  and 
reducing  the  storage  of  TM  data  with  electronic  filing  and  archiving  ideally  creating  a 
data  repository;  (2)  reducing  the  costs  associated  with  printing  and  distributing  TMs  by 
providing  on-line  access  to  this  repository,  so  that  naval  personnel  could  access  the 
data  repository  from  their  field  activity  and  view  and/or  print  the  specific  TMs  they 
require;  and  (3)  eliminating  the  need  for  field  activities  to  incorporate  change  pages  by 
keeping  the  data  repository's  TM  data  current.  Also,  this  data  repository  may 
incorporate  other  related  data  to  form  a  knowledge  base  to  aid  in  the  creation  of  lETMs. 
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3.4.1  Nondigital  Data  D«liv«rablM 

3.4.1 .1  Paper 

Paper  or  Rnai  Reprodudbie  Copy  (FRC)  has  long  been  the  traditional  media  for 
delivery  of  Navy  product  data  and  related  information.  TMs  delivered  on  this  meda 
may  have  originated  from  many  sources  including  other  existing  paper  documentation, 
microfiche,  microfilm,  or  any  of  the  digital  data  formats  described  in  the  following 
sections.  TMs  originating  on  this  media  are  governed  by  standards  such  as 
MIL-M-38784  and  MIL<M-81927(AS). 

Since  paper  is  not  a  digital  form  of  media,  no  digital  data  infrastructure  requiremertts 
are  necessary.  However,  converting  the  data  content  of  paper  to  a  digital  data  format 
requires  infrastructure  systems  that  include  scanning  hardware  and  software  to  support 
the  conversion  of  both  text  and  graphics  from  hardcopy  to  electronic  format.  The  TM 
Print-On-Oemand  System  (TMPOOS)  supports  this  type  of  paper-to-digitai  format 
conversion  process  (see  Appendix  C,  TMPOOS). 

Since  paper  documents  are  difficult  to  maintain  and  update,  it  is  not  expedient  to  obtain 
them  Instead  of  digital  data.  Scan  ng  a  document  into  TMPOOS  is  most  useful  when 
used  with  legacy  data 

NOTE:  The  acquisition  management  team  should  accept  paper  deliverables  only  for 
the  purpose  of  verifying  the  digital  deliverables. 

3.4.1  Microftehe/MIcrofilm 

Microfiche  and  microfilm  are  other  traditicnal  media  for  delivery  of  data  to  the  Navy.  It 
is  not  a  recommended  mpdia  for  obtaining  new  data  but  it  is  discussed  here  since 
legacy  data  in  this  form  ^ready  exists.  The  data  provided  on  microfiche  and  microfilm 
are  governed  by  specifi«bations,  such  as  MIL-M-38748  and  MIL-M-9868,  which  provide 
guidelines  for  data  fon^at  and  content.  Converting  the  data  contents  of  microfiche  or 
microfilm  to  a  mord  flexible  digital  data  format  requires  additional  infrastructure 
requirements  that  include  scanning  hardware  and  software  to  support  both  text  and 
graphics.  TMPOOS  also  supports  the  conversion  of  microfiche  and  microfilm  to  a 
digital  form  (see  Appendix  C,  TMPOOS) 

3.4.2  Digitai  Data  Deliverables 

Digital  data  deliverables  available  in  the  CALS  environment  are  extensive.  Digital  data 
provides  the  acquisition  management  team  with  a  variety  of  digital  data  formats  and 
media  options.  For  TM  delivery,  the  list  includes: 

Data  Formats: 

•  Raster 

•  Illustrated  Text  Data  Files: 
a)  Text: 

1)  American  Standards  Code  for  Information  Interchange  (ASCII) 

2)  Standard  Generalized  Markup  Language  (SGML) 


11 


b)  Illustrations: 

1)  Computer  Graphics  Metafile  (CGM) 

2)  Initial  Graphics  Exchange  Specification  (IGES) 

3)  Raster 

c)  PDL 
•  lETM 


Media 

•  MIL-STD-1 840  magnetic  tape 

•  Magnetic  disk 

•  Optical  disk 

•  CITIS  -  interactive  access 

3.5  Life  Cycle  Considerations 

TMs  are  developed  using  LSAR  and  engineering  drawings  as  source  data  i  he  LSAR 
consolidates  logistics-oriented  technical  information  in  conjunction  with  data  from  the 
various  engineering  disciplines  and  Integrated  Logistic  Support  (ILS)  elements  to 
reduce  redundancy,  facilitate  timely  usage,  and  enhance  consistency  among  data 
elements  and  disciplines.  The  quality  and  productivity  of  TM  development  are 
enhanced  when  the  LSAR  is  used  as  a  principal  data  source  for  this  process. 
Integration  of  the  databases  that  produce  LSAR  task  analysis  (and  other)  data,  TMs, 
and  training  materials  will  provide  even  greater  benefits  to  the  defense  systems 
program. 

TMs  are  generally  i  ot  required  until  the  later  acquisition  life-cycle  phases  of  a  defense 
system  program.  In  addition,  TMs  availat^e  during  these  earlier  phases  may  be 
preliminary  copies  that  have  not  been  verified  or  have  not  received  final  acceptance  but 
are  useful  for  test  verification,  training,  and  operation.  FRCs  are  available  in  the  later 
phases.  The  acquisition  management  team  must  also  consider  the  information  volume 
and  typical  use  (see  3.3.2)  to  determine  the  appropriate  TM  deliverable  format. 

3.6  CDRLs 

Deliveiy  of  defense  system  data  in  digital  form  requires  changes  to  Navy  solicitations 
and  contracts  m  iding  thf  '  '<■  -.ents  and  enclosures.  These  changes  should  be 

made  with  full  cnr  n  of  the  ability  of  Navy  activities  to  make  cost  effective  use 

ot  digital  data  deliverables  or  access.  Each  defense  system  program  may  include 
unique  requirements  for  which  additional  program-specific  tailoring  will  be  needed. 
Most  of  the  applicable  CALS  standards  and  specifications  contain  contract-negotiable 
options  from  which  the  acquisition  management  team  must  choose  to  satisfy  program- 
specific  requirements  including  multiple  classes  or  types  of  data  formats. 

The  TM  Contract  Requirements  (TMCRs)  vA.ill  iderrtify  the  types  of  TMs  required  and 
include  language  that  specifies  exactly  how  data  will  be  delivered  (including  media, 
format,  and  content)  under  the  contract.  However,  the  TMCR  does  not  address 
software  TM  requirements  such  as  operator  manuals,  systems  operator  manuals,  etc. 
In  the  case  of  software  manuals,  the  Statement  of  Work  (SOW)  and  CDRL  will  specify 
the  TM-related  data  requirements  and  their  preparation  and  delivery.  CAlS  standards 
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should  be  invoked,  whenever  possible,  for  digital  delivery  of  support  products  such  as 
engineering  drawings  and  TMs.  The  media  for  delivery  such  as  magnetic  tape,  optical 
disk,  or  on-line  (networks  or  telephone  modems)  should  be  compatible  with 
Government-receiving  system  capabilities.  Some  digit^  deliverables,  especially  interim 
deliverables,  may  be  efficiently  acquired  by  agreeing  on  a  common  word  processing 
package  in  the  contract  and  specifying  the  appropriate  and  compatible  physical  media 
such  as  magnetic  disk,  magnetic  tape,  etc. 
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4.0  SPECIRC  CONSIDERATIONS 

Once  the  general  considerations  have  been  reviewed,  an  additional  process  of 
determining  how  to  implement  these  decisions  must  be  accomplished.  The  information 
contained  in  this  section  provides  a  process  for  selecting  which  options  are  best  suited 
for  the  defense  system  program  objectives.  It  should  be  noted  that  certain 
considerations  must  be  accomplished  concurrently.  The  options  must  be  evaluated  for 
usefulness  with  respect  to  each  phase  of  the  defense  system's  life  cycle  and  whether 
the  defense  system  program's  infrastructure  can  support  a  particular  option.  Once  the 
most  suitable  options  have  been  selected,  the  process  to  validate  and  verify  these 
options  should  be  determined. 

The  following  sections  discuss  additional  topics  of  consideration  that  must  be 
addressed. 

•  Deliverable  formats  and  media  selection 

•  Determination  of  level  of  TM  development  or  modification 

•  Cost  issues  associated  with  the  selected  deliverable  option 

•  Sample  language  for  contract  deliverables. 

4.1  TM  Delivery  Format  Selection  (see  figure  3) 

The  purpose  of  this  section  is  to  determine  the  status  and/or  existence  of  the  TM  and 
ultimately  to  lead  the  acquisition  management  team  to  a  decision  as  to  the  specific  type 
of  digital  data  and  media  format  required  to  support  the  defense  system  program.  In 
addition  to  the  immediate  TM  requirements  (acquire  and/or  develop  a  TM),  an  important 
consideration  is  that  the  acquisition  management  team  should  be  concerned  with  the 
potential  long  term  engineering  and  support  functions  and  requirements  when 
procuring  the  TM. 

4.1 .1  TM  Delivery  Options 

4.1 .1.1  Raster 

Raster  data  is  a  binary  representation  of  an  image.  Raster  may  be  thought  of  as  the 
electronic  version  of  a  paper  document.  It  contains  no  intelligence  and  must  be 
reviewed  through  human  interpretation.  There  are  two  types  of  raster  data,  tiled  and 
untiled.  A  tiled  raster  image  resembles  a  two-dimensional  grid  with  each  "tile"  or  set  of 
pixels  representing  a  portion  of  the  image.  Formatted  raster  can  be  either  tiled  or 
untiled.  Text  and  graphics  in  raster  data  formats  are  stored  digitally,  which  allows  more 
rapid  and  consistent  access  to  the  stored  images  than  paper.  In  addition,  raster  data 
formats  can  be  sent  via  electronic  means  to  remote  sites.  Through  a  difficult  process, 
raster  files  can  also  be  converted  to  digital  (word  processor  or  desk  top  publishing) 
documents  and  edited  through  manipulation  of  individual  pixels. 
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FIGURE  3.  TM  Delivery  Format  Selection  Flow  Chart 

With  the  advent  of  raster  scanning  technologies,  the  ability  to  convert  existing  paper 
TM  to  digital  data  files  has  become  available.  Raster  conversion  became  the  easiest 
and  most  cost  effective  method  for  digitizing  the  Navy's  existing  paper  TMs.  However, 
the  quality  assurance  (QA)  process  by  human  interpretation  required  to  verify  the  data 
contents  may  increase  costs  substantially.  Also,  raster  image  files  require  a  large 
amount  of  memory  storage  due  to  their  file  stmcture  and  contain  no  additional 


information  other  than  each  tile's  position  on  a  grid.  Technologies  are  evolving  that  will 
be  able  to  convert  the  raster  images  to  other  digital  forms  (such  as  vector)  for 
processing,  but  the  acquisition  management  team  should  consider  other  processable 
data  form's  first  unless  the  TMs  required  are  legacy  data.  TMPODS  stores  drawing 
images  as  raster  data  on  optical  disk  media  (see  Appendix  C,  TMPODS). 

4.1 .1.2  Illustrated  Text  Data  Files 

Illustrated  text  data  files  provide  a  dynamic  form  of  source  data  with  two  possibilities: 
(1)  Separated  files  for  text,  graphics,  alphanumeric  and  audio/visual  data;  or  (2) 
integrated  files  consolidating  some  or  all  of  these  different  data  representations.  Text 
data  files  include  word  processing  and  desk  top  publishing  applications.  Such  data 
files  can  provide  the  source  data  for  multiple  data  applications  that  allow  creation  of 
standard  and  custom  documents  as  well  as  manipulation  of  the  data  for 
annotate/excerpt  or  update/maintain  purposes.  Illustrated  text  data  files  can  also 
import  generic  text  [ASCII,  SGML  (MIL-M-28001),  etc.]  and  graphics  (raster 
(MIL-R-28(X)2),  CGM  (MIL-D-28003),  IGES  (MIL-D-28000),  etc.]  from  other  sources  that 
may  be  otherwise  incompatible.  In  addition,  there  are  PDLs,  sometimes  called  text 
presentation  metafiles,  which  are  used  to  drive  output  devices  such  as  printers. 

There  may  be  instances  when  obtaining  illustrated  text  data  files  involves  obtaining 
more  than  one  format  of  graphical  data.  This  may  be  due  to  multiple  graphic  sources. 
This  is  an  acceptable  and  highly  likely  situation.  The  acquisition  management  team 
must  be  aware  of  this  possibility  and  be  prepared  to  develop/modify  the  defense 
system  contract  requirements  accordingly. 

Text  Formats: 

There  are  two  possible  text  formats  for  consideration.  They  are  the  ASCII  and  tagged 
ASCII  or  Standard  Generalized  Markup  Language  (SGML).  They  are  described  below. 

•  ASCII 

ASCII  was  developed  as  a  method  of  translation  for  computer  processors  to 
interpret  alphanumeric  characters  and  symbols  through  binary  representation. 
ASCII  is  the  basic  text  information  used  by  most  word  processing  applications 
and  contains  no  formatting  information  other  than  line  feed  and/or  carriage 
returns.  Word  processing  applications  can  import  ASCII  text  from  other  word 
processing  applications,  and  some  word  processing  applications  can  translate 
formatted  ASCII  from  other  word  processing  applications  into  their  own  format. 
This  makes  ASCII  text  ideal  for  most  interim  deliverables  since  it  can  also  be 
imported  into  an  SGML  application  where  it  can  be  SGML-tagged  to  become  a 
CALS-compliant  deliverable. 

•  SGML 

SGML  as  defined  in  MIL-STD-1840  is  "A  standard  that  defines  a  language  for 
document  representation  which  formalizes  markup  and  frees  it  of  system  and 
processing  dependencies.  It  provides  a  coherent  and  unambiguous  syntax  for 
describing  whatever  a  user  chooses  to  identify  within  a  document."  In  the 
SGML  scheme,  the  document  contains  only  generic  tags  identifying  such 
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structural  elements  as  paragraphs,  sections,  etc.  but  no  typesetting  markup. 
However,  SGML's  tagging  of  ASCII  text  is  a  rather  cumbersome  proposition  and 
may  be  best  suited  for  final  data  deliverables  rather  than  interim  deliverables. 
When  considering  SGML  as  a  deliverable  format,  the  acquisition  management 
team  must  determine  whether  the  necessary  computer  environment  is  available 
and  in  place  to  accept  the  SGML  documentation.  Any  TMs  that  will  be 
maintained  throughout  the  life  cycle  of  a  defense  system  should  be  delivered  in 
SGML  format.  The  Format  Output  Specification  Instance  (FOSI)  is  an 
application  that  can  output  the  same  SGML  document  in  different  formats.  The 
same  SGML  tagged  document  could  have  two  or  more  FOSI's  so  that  the  same 
document  can  be  printed  on  different  publishing  systems.  Additional  features 
associated  with  SGML  are  described  in  Appendix  A  [see  Document  Type 
Definition  (DTD),  Output  Specification  (OS),  and  FOSI). 

Graphics  and  Illustration  Formats: 

There  are  three  possible  g-aphics  formats  for  consideration.  They  are  Computer 
Graphics  Metafile  (CGM),  Initial  Graphics  Exchange  Specification  (IGES),  and  raster. 
They  are  described  below. 

•  CGM 

CGM  data  is  a  two-dimensional  vector  presentation  used  primarily  for  charts, 
figures,  and  simple  drawings.  Many  types  of  TMs  contain  illustration  data  in  this 
category.  This  is  the  preferred  format  for  obtaining  graphical  digital  data  into 
TMs.  CGM  requirements  are  stated  in  MIL-D-28003. 

•  IGES 

IGES  data  is  a  three-dimensional  vector  presentation  used  primarily  for 
engineering  drawings.  IGES  may  be  the  preferred  choice  for  graphical  data  if  a 
CAD  database  was  used  as  the  source.  IGES  requirements  are  stated  in 
MIL-D-28000. 

•  Raster 

See  4. 1 . 1 . 1  for  discussion  of  raster. 

PDL: 

A  PDL  file  is  executed  by  an  interpreter  that  controls  a  raster  printer  or  other  output 
device.  A  PDL  can  be  used  to  ensure  that  the  composed  document  produced  by  an 
electronic  publishing  system  (which  may  impose  additional  processing  limitations,  such 
as  font  variations,  kerning,  or  hyphenation)  would  produce  nearly  identical  hardcopy 
output  on  the  widest  possible  spectrum  of  printer  devices.  MIL-STD-1840  provides  for 
the  interchange  of  PDL  data  files.  However,  PDLs  are  currency  not  standardized,  for  a 
Standard  Page  Description  Language  (SPDL)  is  still  being  developed.  MIL-STD-1840 
requires  that  a  system  must  provide  portability  of  files  (PostScript  or  Impress  PDL 
specifications).  PDL  document  image  files  can  be  acquired  as  interim  deliverables  or 
as  final  deliverables  in  addition  to,  but  not  in  place  of,  other  digital  data  deliverables. 


17 


4.1.1 .3  Interactive  Electronic  TM  (lETM) 

An  lETM  is  a  computer-based  collection  of  information  needed  for  the  diagnosis  and 
maintenance  of  a  defense  system.  It  is  optically  arranged  and  formatted  for  interactive 
presentation  to  the  end  user  on  an  electronic  display  system.  Unlike  other  optical 
systems  that  display  a  page  of  text  from  a  single  document.  lETMs  present  interrelated 
information  from  multiple  sources  tailored  to  user  queries.  Currently,  lETMs  are  being 
developed  by  the  AEGIS  program  to  mn  on  the  ATIS  platform  (see  /4>pendix  C). 

Specifications  and  other  items  to  define  lETMs  are: 

•  MIL-D-87269,  Data  Base,  Revisable:  Interactive  Electronic  Technical  Manuals, 
for  the  Support  of 

•  MIL-M-87268,  Manuals,  Interactive  Electronic  Technical:  General  Content, 
Style,  Format,  and  User-Interaction  Requirements 

•  MIL-Q-87270.  Quality  Assurance  Program:  Interactive  Electronic  Technical 
Manuals  and  Associated  Technical  Information:  Requirements  for 

•  Hypertext  and  Hotspots. 

A  hypertext  documerrt  consists  of  a  coilection  of  "interconnected  writings."  These 
interconnections  allow  a  user  to  browse  through  a  document  by  selecting  points  of 
interest  or  hotspots  that  may  be  connected  to  other  related  hotspots  or  menus.  The 
user  could  then  continue  to  follow  along  these  "paths"  to  other  cross-referenced  points 
in  that  collection  of  writings.  This  creates  a  "pageiess"  document  that,  depending  on 
the  source  database,  can  contain  a  collection  of  information  from  a  variety  of  sources. 
Also,  rather  than  limit  these  documents  to  pure  text,  we  may  incorporate  graphics, 
audio,  video,  and/or  computer  programs  into  the  content  of  the  document  creating  what 
is  known  as  a  hypermedia  document. 

By  streamlining  access  to  the  desired  information  and  by  providing  multiple  paths  to 
other  related  information,  the  lETM  offers  a  more  efficient  and  more  comprehensive 
method  of  using  technical  information.  Unrestricted  by  the  page-oriented  display  and 
the  use  of  sole-source  information,  the  lETM  duplicates  on  the  personal  computer  (PC), 
the  research  environment  available  in  a  well-equipped  multimedia  library;  displays  only 
the  actions  appropriate  for  resolving  a  specific  problem;  provides  fault-isolation  tables 
and  diagrams;  and  guides  the  technician  through  the  troubleshooting  process  via  a 
user-friendly  query  method.  lETMs  permit  the  user  to  locate  information  more  easily 
and  to  present  it  faster  and  more  comprehensively  in  a  form  that  requires  much  less 
storage  than  paper. 

Derived  from  the  LSAR  and  CAD  data,  the  lETM  will  inherently  become  an  integral  part 
of  the  defense  system  for  the  outset.  Data  created  throughout  the  defense  system's 
life  cycle  will  contain  all  of  the  information  needed  to  create  and  revise  the  necessary 
lETMs  for  the  program. 

lETMs  require  a  computer  environment  with  the  appropriate  presentation  systems  and 
software  to  invoke  them. 
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4.2  lETM  Viability  (see  figure  4) 


The  acquisition  management  team  should  consider  whether  the  TM  will  ultimately  be 
used  in  an  interactive  computer  environment,  the  lETM.  The  lETM  format  offers  the 
user  distinct  advantages  over  the  traditional  TM.  Some  lETM  benefits  include:  (1) 
Reduction  in  the  false  removal  rate  of  Line  Replaceable  Units  (LRUs)  or  Weapon 
Replaceable  Assemblies  (WRAs);  (2)  reduction  in  troubleshooting  time;  (3)  reduction  in 
the  TM  support  costs  associated  with  distribution,  management,  and  storage;  and  (4) 
allowing  training  activities  to  concentrate  more  on  generalized  training  vice  system 
specific  training.  The  acquisition  management  team  should  first  determine  whether  the 
end  item  or  defense  system  program  is  currently  in  the  early  phases  of  design,  whether 
the  life  cycle  requirements  for  the  TM  exceed  five  years,  aod  whether  the  TOP  or  LSAR 
database  contains,  or  can  be  economically  altered  to  include,  a  numbering  system 
similar  to  MIL-STD-1808.  If  any  of  these  considerations  can  be  answered  "NO,“  then 
an  lETM  is  not  recommended;  proceed  to  4.4.  If  all  considerations  can  be  answered 
"YES,“  then  a  business  case  analysis  should  be  performed  to  determine  the  economic 
feasibility  of  the  lETM.  If  results  from  this  analysis  recommend  pursuing  an  lETM  or 
quality  readiness  and/or  support  factors  lend  adequate  credence  to  the  need  for  an 
lETM,  development  of  an  lETM  should  be  pursued.  In  this  case,  go  to  4.3. 

4.3  lETM  Development  (see  figure  5) 

Once  lETM  development  has  been  selected,  the  acquisition  management  team  must 
first  determine  whether  this  effort  will  be  associated  with  an  existing  lETM.  This  may 
include  the  modification  of  an  existing  lETM  the  creation  of  a  supplement  to  an 
existing  lETM.  If  this  is  indeed  the  case,  then  the  acquisition  management  team  must 
determine  whether  an  existing  infrastructure  and  display  device  will  be  used  in 
conjunction  with  the  lETM  and  whether  this  infrastructure  uses  a  proprietary  format.  If 
all  of  the  above  conditions  are  true,  then  the  final  lETM  developed  should  remain  in  the 
existing  proprietary  format.  However,  if  aoy  of  these  conditions  is  not  met,  then  it  is 
advised  that  the  lETM  be  developed  using  the  new  lETM  standards.  See  "NOTE" 
below  and  proceed  to  4.8. 

NOTE:  For  both  cases  stated  above,  any  existing  source  or  legacy  data  used  to 
develop  the  lETM  that  is  not  presently  in  a  digital  format  should  be  converted  to  an 
acceptable  digital  format  for  proper  utilization  in  the  lETM  format.  All  appropriate 
standards  and  specifications  should  be  used  in  converting  and/or  developing  the 
re''" i red  data. 
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4.4  Existing  TM  Availability 

Utilization  of  existing  TMs  and  legacy  data  is  likely  in  the  development  of  completely 
new  systems  with  similar  features.  The  acquisition  management  team  should  be  aware 
that  even  on  completely  new  defense  system  programs  some  portion  of  the  TMs  may 
exist  in  both  digital  and  nondigital  formats.  This  is  most  relevant  when  a  program  is 
entering  the  earlier  life  cycle  pnases.  An  important  point  to  remember  here  is  that 
acquisition  of  the  proper  level  a  d  type  of  digital  data  is  most  cost  effective  when 
defined  early  in  the  program's  life  cycle.  If  the  TM  does  not  exist  and/or  is  not 
accessible  to  the  Government,  the  acquisition  management  team  should  consider 
developing  a  new  TM  (see  figure  8  and  4.5).  If  the  TM  does  exist,  the  acquisition 
management  team  should  proceed  to  4.4.2,  unless  the  acquisition  effort  is  associated 
with  the  modification,  revision,  update,  or  issue  of  an  existing  commercial  TM.  In  that 
case,  go  to  4.4.1. 

4.4.1  Commercial  TM  Usage 

Another  consideration  the  acquisition  management  team  must  address  is  whether 
existing  off-the-shelf  TMs  will  satisfy  the  program’s  TM  requirements.  If  more  than  90 
percent  of  the  TM  conforms  to  the  technical  content  requirements  defined  in  MIL-M- 
7298  and  supports  the  maintenance  concept  of  the  equipment,  the  commercial  TM  may 
be  used.  In  this  case,  go  to  4.4. 1.1.  However,  if  more  than  10  percent  of  the 
proposed  TM  fails  to  meet  the  necessary  requirements  to  support  the  equipment,  a  new 
TM  should  be  developed.  If  this  is  the  case,  go  to  4.5. 

4.4.1 .1  Commercial  TM  Development  (see  figure  6) 

Once  it  has  been  determined  that  a  commercial  TM  will  satisfy  the  technical 
requirements  and  maintenance  concept  of  the  equipment,  the  acquisition  management 
team  must  determine  the  present  format  of  the  commercial  TM  and  whether  change 
pages  and/or  a  TM  supplement  will  be  required.  If  the  "basic"  TM  is  available  in  a  word 
processor  format,  the  TM  may  be  delivered  in  its  present  format  providing  that  this  is 
mutually  compatible  with  the  existing  infrastructures.  In  this  case,  go  to  4.7.  If  it  is  not, 
the  TM  should  be  delivered  in  raster  format.  In  this  case,  go  to  4.6.  Also,  if  change 
pages  and/or  a  TM  supplement  will  be  required  in  addition  to,  or  instead  of,  the  "basic" 
TM,  then  the  development  of  these  items  is  the  same  as  that  required  for  a  new  TM 
except  that  the  format  and  style  of  the  newly  developed  items  may  remain  the  same  a^ 
the  "basic"  TM.  Go  to  4.5. 
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Premise.  90  percent  of  Commercial  TM  saltsiies  technical  requiremenis  at 
MIL'M-7296  and  the  mainlenance  concept  ol  the  End  Iiem43steme  System 


'<■ 


_ 4 _ 
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FIGURE  6.  Acquisition  of  Commercial  TM  Decision  Flow  Chart 
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4.4.2  Revisions  to  Existing  Military  TMs 


The  acquisition  management  team  must  now  determine  how  well  the  existing  military 
TMs  cover  the  maintenance  concepts  of  the  equipment.  Changes  to  the  hardware 
configuration  or  equipment  components  of  the  defense  system  may  impact  upon  the 
accuracy  of  the  TM's  information.  If  less  than  25  percent  of  the  TM  is  affected  by 
configuration  changes,  proceed  to  4.4.2. 1 .  If  more  than  25  percent  of  the  existing  TM 
is  affected  by  these  configuration  changes,  complete  revision  of  the  TM  is 
recommended.  Proceed  to  4.5.  However,  if  the  configuration  changes  affect  the 
existing  TM  in  a  range  somewhere  in  between  these  two  extremes,  proceed  to  4. 4. 2. 2. 

4.4.2.1  TM  Permanent  Change  Page  Development  (see  figure  7) 

Once  it  has  been  determined  that  less  than  25  percent  of  the  TM  needs  revision,  only 
change  pages  will  be  developed.  The  basic  TM  will  be  converted  to  raster  if  it  is  not 
already  digitized.  Change  page  development  will  follow  the  same  decision  path  as  the 
development  of  a  new  TM,  but  the  newly  created  change  pages  will  retain  the  format 
and  st^e  of  the  original  TM.  Proceed  to  4.5. 

4.4.2.2  TM  Update  Revision  Development 

Once  it  has  been  determined  that  more  than  25  percent  of  the  TM  must  be  changed, 
the  acquisition  management  team  must  decide  how  the  final  product  will  be  delivered. 
The  decision  process  follows  the  same  basic  path  as  that  stated  for  a  newly  developed 
TM  (see  figure  8);  the  difference  is  the  revised  TM  may  retain  the  format  and  style  of 
the  original  TM.  Proceed  to  4.5. 

4.5  New  TM,  Complete  Revision,  or  Update  Revision  Development 

(see  figure  8) 

4.5.1  Source  and  Legacy  Data  Considerations 

The  acquisition  management  team  must  now  consider  whether  any  of  the  TM  source 
data  presently  exists  as  legacy  data.  Legacy  data  developed  from  existing  defense 
systems  or  from  the  creation  of  LSA  data  may  contain  enough  information  to  warrant 
inclusion  into  the  new  defense  system  program. 

NOTE:  r\,r  newer  defense  system  programs,  this  legacy  data  ma^  exist  in  both  digital 
and  nond,i;ital  formats. 
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Notes 

<t)  Mutually  agreeable  propnelaiy  wwd  processu 
applicalion  software 

(2)  The  term  'FRC*  is  used  in  relerence  to  a  digital 
tile  capable  ol  producing  a  camera-ready  copy 

(3)  Specific  conversion  tormal  based  on  economic 
analysis,  e  g  while  some  paper  legacy  and 
source  data  should  be  scanned  into  a  .aster 
tormal.  other  illustrations  should  be  recreated 
u  convened  to  a  veclu  lumat 

(d)  The  arfvantages  ol  requiring  preliminary  and 
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FIGURE  7.  TM  Permanent  Change  Page  Decision  Flow  Chart 
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Premise:  TM  does  not  exist  in  any  form,  or  more  than  25% 
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FIGURE  8.  New,  Complete  Revision,  or  Update  Revision  to  an  Existing  TM 

Decision  Flow  Chart 
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If  legacy  data  does  exist  in  a  digital  format,  the  acquisition  management  team  should 
proceed  to  4.5.3  to  address  life  cycle  considerations.  If  no  legacy  data  is  to  be 
procured  for  the  defense  system’s  TMs  or  no  digital  legacy  data  exists,  the  acquisition 
management  team  should  consider  whether  configuration  changes  and/or  multiple 
configurations  are  anticipated  for  the  end  item  or  defense  system.  Go  to  4.5.2. 

4.5.2  Defense  System  Configuration  Considerations 

Configuration  differences  may  play  an  important  part  in  the  acquisition  of  defense 
system  TMs.  The  differences  may  be  as  small  as  printed  circuit  card  modifications  or 
as  large  as  entire  equipment  changes.  The  acquisition  management  team  must 
determine  whether  multiple  configurations  will  exist.  A  different  TM  may  be  procured 
for  each  configuration.  Another  consideration  is  whether  future  changes  to  the  TM  are 
anticipated.  If  multiple  configurations  and/or  configuration  changes  are  anticipated, 
conversion  of  the  source  or  legacy  data  to  digital  format  is  recommended.  Specific 
conversion  format  may  be  based  on  an  economic  analysis  that  may  recommend  some 
paper  legacy  and  source  data  simply  be  scanned  into  a  raster  format  and  other 
illustrations  be  recreated/converted  to  a  vector  format.  In  this  case,  proceed  to  4.5.3.  If 
this  is  not  the  case,  the  defense  system  program  should  consider  delivery  of  the  TM  in 
raster  format  for  both  text  and  graphics.  Go  to  4.6. 

4.5.3  Program  Life  Cycle  Considerations 

The  acquisition  management  team  must  now  consider  the  current  phase  of  the  end 
item  or  defense  system  program  and  the  anticipated  requirements  for  the  TMs.  If  the 
end  item  or  defense  system  program  is  currently  in  the  later  phase(s)  of  its  life  cycle 
and  the  TM  requirements  are  anticipated  to  be  fewer  than  five  years,  the  need  to 
deliver  SGML-formatted  TMs  is  not  recommended,  espec  ally  since  most  of  the  data  for 
the  TMs  may  be  in  hard  copy  or  proprietary  digital  format.  If  this  is  indeed  the  case, 
delivery  of  both  review  and  Final  Reproducible  Copies  (FRC)  of  the  TMs  in  a  mutually 
agreeable  format  is  recommended.  Go  to  4.7.  If  the  TM  requirements  are  anticipated 
to  be  at  least  five  years  aod  this  TM  development  process  is  concerned  with  a  TM 
Update  Revision,  proceed  to  4.5.4.  Othenwise,  go  to  4.5.5. 

NOTE:  The  term  "FCR"  is  used  in  reference  to  a  digital  file  capable  of  producing  a  final 
reproducible  copy. 

4.5.4  Additional  TM  Update  Revision  Decisions  (see  figure  9) 

As  discussed  in  4.4.2.2,  a  TM  Update  Revision  may  retain  the  style  and  format  of  the 
original  TM.  With  this  in  mind,  additional  considerations  concerning  SGML  formatting 
arise.  DTDs  may  exist  that  support  the  modification  of  the  original  TM  while  retaining 
the  original  style  and  format.  If  these  DTDs  do  exist,  then  proceed  to  4.5.5.  If  these 
DTDs  do  not  exist,  then  the  acquisition  management  team  must  consider,  through 
economic  analysis,  whether  it  is  cost  effective  to  modify  or  create  a  DTD  to  satisfy  the 
style  and  format  requirements  of  the  original  TM.  If  it  is  determined  to  be  economically 
practical,  proceed  to  4.5.5.  If  not,  it  is  recommended  that  the  new  TM  Update  Revision 
be  delivered  in  a  mutually  agreeable  format  for  both  text  and  illustrations.  Go  to  4.7. 


27 


Premise:  TM  changes  over  25  percent. 


Return  to  figure  8. 


Return  to 
figures. 


FIGURE  9.  TM  Update  Revision  Decision  Flow  Chart 


4.5.5  Conversion  of  Illustrations 


The  acquisition  management  team  must  now  determine,  through  economic  analysis, 
whether  conversion  of  all  existing  illustrations  is  justified.  Conversion  in  this  case 
means  converting  nonvector  illustrations,  both  source  and  legacy  data  that  currently 
exists  in  ras  r  and  h?»'  c  ,  ;  '^rmats,  into  a  vector  format.  If  it  is  determined  that 
conversion  ,ig  nonvector  illustrations  to  a  vector  format  is  cost  effective  or  if 

no  source  or  legacy  illustrations  exist,  then  the  recommended  solution  would  be  to 
convert  and/or  create  all  applicable  illustrations  to  a  vector  format,  IGES  or  CGM.  If 
economic  analysis  determines  that  conversion  of  all  existing  illustrations  is  not  practical, 
it  is  recommended  that  only  selected  source  or  legacy  illustrations  (those  with  a  high 
likelihood  of  being  revised  at  a  later  date)  be  converted  to  a  vector  format.  Remaining 
illustrations  should  be  delivered  in  raster  format.  In  either  case,  see  "NOTE"  and  go  to 
4.7. 


NOTE:  To  provide  maximum  proliferation  of  the  preliminary  TMs  for  review,  it  may  be 
beneficial  to  request  that  these  deliverables  be  provided  in  a  proprietary  word 
processor  format  with  illustrations  in  either  raster  and/or  CGM  formats  only.  SGML, 
IGES  or  commercial  CAD  should  not  be  used  at  this  point  unless  it  can  be 
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demonstrated  that  the  reviewing  activities'  infrastructure  can  support  display  and 
annotation. 

4.6  Document  Image  Files  (Raster,  PDL) 

The  document  image  file  delivery  option,  which  consists  of  either  raster  (see  4.1 .1.1)  or 
PDL  (See  4.1 .1.2)  files,  allows  the  acquisition  management  team  to  obtain  TM  data  in  a 
digital  format.  The  data  uses  of  the  document  image  file  deliverables  are  somewhat 
limited  but  do  provide  for  view,  archive,  comment,  and  annotate  capabilities.  Also 
CITIS,  if  available,  provides  another  method  for  delivery  of  preliminary  deliverables. 
The  GCO  is  designed  to  assist  the  acquisition  management  team  in  determining  CITIS 
availability.  Suggested  delivery  media  options  (see  figure  10)  include:  (1)  Optical  disk 
or  CD-ROM,  (2)  Magnetic  disk,  or  (3)  9-track  magnetic  tape,  all  in  accordance  with  MIL- 
STD-1840. 

NOTE:  Paper  TMs  may  be  requested  in  addition  to  the  document  image  file 
deliverables  but  only  for  verification  of  the  document  image  file  data. 

4.6.1  Cost 

Once  the  data  delivery  format  selected  is  in  document  image  files,  the  cost  of  acquiring 
this  data  can  be  calculated.  Figure  11  is  designed  to  assist  the  acquisition 
management  team  in  determining  all  the  steps  associated  with  both  the  creation  and/or 
conversion  of  the  TM  deliverable  and,  used  in  conjunction  with  table  1 ,  will  determine 
the  approximate  total  cost  of  this  process.  Costs  associated  with  paper  TM  delivery 
and/or  on-line  delivery  using  CITIS  have  not  been  included  in  this  document. 

NOTE:  Table  1  provides  an  approximation  of  costs  associated  with  this  data 
deliverable.  Specific  program  requirements  may  vary  from  those  presented  here  and 
may  be  substituted  for  the  rates  shown. 
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Setsct  aH  ipphcabla  TM 
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Premise:  Source  data  arKi  output  formats  have 


FIGURE  1 1 .  Develop  Cost  Estimate  Decision  Flow  Chart 
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TABLE  1 .  Cost  Associated  with  Developing/Converting  the  Deliverable  Options 


ProMSS 

Note 

1 
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Oiagm 
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Btposed 
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S 

40 

4.0 

40 

40 
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60 

15  5 

Create  in  WP  format 
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60 

65 

55 

65 

70 

80 

20.0 

C 

120 

70 

75 

90 

90 

10.0 

400 

ii^m 

S 

30 

3.0 

3.0 

40 

50 

60 

15  5 

Create  in  SGML  format 

1 

WEM 

45 

45 

65 

70 

80 

20.0 

C 

9.0 

5.5 

60 

90 

90 

100 

400 

1  Scan  &  Convert  to  WP 

1  Scan  &  Convert  to  SGML 

1  Scan  &  Corwert  to  Raster 

$200/Pfl  1 

hhihhbhhhih 

[  Convert  from  WP  to  SGML 

$1400/Pa  1 

■HI 

1  Validate/Verlfv  TM 

4.6.2  CDRLs 

To  invoke  this  data  deliverable  option,  specific  TMCRs  and  CDRLs  must  be  developed 
to  identify  the  types  of  TMs  required  and  include  language  that  specifies  exactly  how 
data  will  be  delivered  under  the  contract  including  media,  format  (in  this  case  raster), 
and  content.  To  invoke  this  data  deliverable  option,  a  sample  CDRL  and  a  TMCR 
addendum  sheet  (see  figures  12  and  13)  have  been  developed.  The  sample  CDRL 
may  be  used  for  any  of  the  deliverable  options  by  specifying  the  required  deliverable  as 
indicated.  The  information  contained  in  the  following  contract  vehicles  should  be 
tailored  to  meet  the  requirements  of  the  specific  defense  system  program.  CALS 
standards  should  be  invoked  whenever  possible. 
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CONTRACT  DATA  REQUIREMENTS  UST 

(OMa  Kam) 


Form  Approved 
OMB  No.  0704-0188 


A.  CONTRACT  LINE  ITEM  NO. 

B.  EXHiarr 

C.  CATEGORY 
TOP _ 

TM  X  OTHER 

D  SYSTEM/ITEM 

E,  CONTRACT/PRNO. 

F.  CONTRACTOR 

I  MTAITCMNO  2  'nUEOrMTArTOK 

(Defense  System) 


*Aunamy  n«i ■■iiaiiinnnnim 

SEE  SIX  16 


7  00290 an  I  oaTtTAicHorr  lamEoueor  12 mtrs of hb«t ■a.enaeoN 

NEOUREO 


S.  OOMTaACr  RETEieNCE 


xaurnme 

(Specify  Oeiiverabie) 


a  RECLMNOOEXCE 


lAOUTwemow 


II.AaOFOATE  I  IICMTEOF 


AARROOCE 

A 


laflEMMKS 

6LK  4:  (Add  TMCR  No./Statement  of  Work  Paragraph  No.) 

Note;  Requirements  should  be  specified  in  TMCR/Statement  of  Work. 

BLK  9;  See  1T^CR  (Add  No.)  for  Distribution  Statement 

Note;  See  General  DD  Form  1 423  Glossary  for  instructions  on 
completing  this  form. 


^  G  PREP^tflCOBV  1 

H  DATE  j 

1  AmOVEDQY 

J.  CMSTE 
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TMCR  Attachment  (1) 
ADDENDUM  SHEET 


The  descriptions  below  identify  any  deviations/waivers  or  additions  to  the  requirements 
defined  in  the  referenced  TMCR  paragraphs. 

TMCR  Paragraph  No.  Description 

4. 1  .a  The  text  and  tabular  material  for  both  the  review  and  final 

manuscript  copies  shall  be  delivered  in  a  raster  data  file. 
Navy  Image  RIe  R)rmat  (NIFF)  shall  be  used  for  the 
raster  data  contained  in  a  MIL*R*28002  raster  data  file. 
Additional  requirement  for  raster  data  files  are  contained 
in  SPAWAR-S-903. 

4.1.b  The  illustrations  and  drawings  shall  be  delivered  in  a 

raster  data  file.  Navy  Image  RIe  Format  (NIFF)  shall  be 
used  for  the  raster  data  contained  in  a  MIL-R-28002 
raster  data  file.  Additional  requirements  for  raster  data 
files  are  contained  In  SPAWAR-S-903. 


FIGURE  13.  Sample  TMCR  Addendum  Sheet  for  Raster  Deliverables 

NOTE:  This  addendum  sheet  was  developed  using  Space  and  Naval  Warfare 
Systems  Command  (SPAWAR)  TM  Contract  Requirement  (TMCR).  Any  specific 
paragraphs  listed  in  this  TMCR  addendum  sheet  reference  this  document. 

4.7  Illustrated  Text  Data  Files 

The  illustrated  text  data  file  deliverable  option,  described  in  4. 1.1. 2,  includes  the  vast 
majority  of  data  formats  available  to  the  acquisition  management  team.  Illustrated  text 
data  file  deliverables  provide  the  greatest  flexibility  and  data  manipulation  capabilities. 
It  is  very  important  that  the  acquisition  management  team  know  the  specific  digital  and 
management  irrfrastructure  and  end  user  requirements  when  specifying  this  deliverable 
option  due  to  the  number  of  digital  formats  and  software  applications  available.  Also 
CITIS,  if  available,  provides  another  method  for  delivery  of  preliminary  deliverables. 
The  GCO  is  designed  to  assist  the  acquisition  management  team  in  determining  CITIS 
availability.  Suggested  delivery  media  optior^,  which  may  vary  depending  on  the 
specific  user's  requirements  (see  figure  10),  irKlude:  (1)  Optical  disk  or  CD-ROM,  (2) 
Magnetic  disk,  or  (3)  9-track  magnetic  tape,  all  in  accordance  with  MIL-STD-1840. 

NOTE:  In  addition  to  the  digital  maintenance  copies  of  the  TM,  change  pages,  or  TM 
supplement,  a  rasterized  version  may  also  be  required  by  the  end  user  and/or  the 
distribution  infrastructures.  If  this  is  the  case,  convert  and  integrate  the  new  change 
pages  or  TM  supplement,  as  applicable,  into  the  rasterized  "basic"  TM. 


NOTE:  Paper  TMs  may  be  requested  in  addition  to  the  digital  data  deiiverabies  but 
only  for  verification  of  the  digital  data 

4.7.1  Cost 

Once  this  option  has  been  selected  as  the  data  delivery  format,  the  cost  of  acquiring 
this  data  can  be  calculated.  Rgure  11  is  designed  to  assist  the  acquisition 
management  team  in  determining  all  the  steps  associated  with  both  the  creation  and 
onversion  of  the  TM  deliverable  and.  used  in  conjunction  with  table  1 ,  will  determine 
tl  a  approximate  total  cost  of  this  process. 

NOTE:  Table  1  provides  an  approximation  of  costs  associated  with  this  data 
deliverable.  Specific  program  requiremerrts  may  vary  from  those  presented  here  and 
may  be  substituted  for  the  rates  shown. 

4.7.2  CORLs 

To  invoke  this  data  deliverable  option,  specific  TMCRs  and  CDRLs  must  be  developed 
to  identify  the  type  of  TM  required  and  Include  language  that  specifies  exactly  how  data 
will  be  delivered  under  the  contract  including  media,  format  (in  this  case  a  processable 
text  data  file),  and  content.  To  invoke  this  data  deliverable  option,  a  sample  CDRL  and 
a  TMCR  addendum  sheet  (see  figures  12  and  14)  have  been  developed.  The  sample 
CORL  may  be  used  for  any  of  the  deliverable  options  by  specifying  the  required 
deliverable  as  indicated.  The  information  contained  in  the  following  contract  vehicles 
should  be  tailored  to  meet  the  requirements  of  the  specific  defense  system  program. 
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TMCR  Attachment  (1) 
ADDENDUM  SHEET 


The  descriptions  below  identify  any  deviations/waivefs  or  additions  to  the  requirements 
defined  in  the  referenced  TMCR  paragraphs. 

TMCR  Paragraph  No.  Description 

4.1. a  The  text  and  tabular  material  for  the  review  manuscript 

copy  shall  be  delivered  in  (add  mutually  agreeable  word 
processor  application  software). 

The  text  and  tabular  material  for  the  final  manuscript  copy 
shall  be  delivered  in  SGML-tagged  ASCII  In  accordance 
with  MIL-M-28001.  Additional  requirements  are  contained 
in  Appendix  A  of  the  TMCR. 

4.1  .b  The  review  illustrations  and  drawings  shall  be  delivered  in 

a  raster  d?*a  file.  Navy  Image  File  Format  (NIFF)  shall  be 
used  for  the  raster  data  contained  in  a  MIL-R-28002 
raster  data  file.  Additional  requirements  for  raster  data 
files  are  contained  in  SPAWAR-S-903. 

The  final  illustratiOT>s  and  drawings  shall  be  delivered  in 
IGES  in  accordance  with  MIL-D-28000. 


FIGURE  14.  Sample  TMCR  Addendum  Sheet  for  illustrated  Text  Data  RIe  Deliverables 

NOTE:  This  addendum  sheet  was  developed  using  Space  and  Naval  Warfare 
Systems  Command  (SPAWAR)  TM  Contract  Requirement  (TMCR).  Any  specific 
paragraphs  listed  in  this  TMCR  addendum  sheet  reference  this  document. 

4.8  lETM  Deliverables 


The  lETM  deliverable  option,  described  in  4. 1.1. 3,  is  the  most  dynamic  and 
comprehensive  data  deliverable  option  available  to  the  acquisition  management  team. 
It  is  of  the  utmost  importance  that  the  acquisition  management  team  know  the  specific 
digital  and  management  infrastructure  and  end  user  requirements  when  specifying  this 
deliverable  option  due  to  the  vast  network  of  data  resources  associated  with  an  lETM. 
The  GCO  is  designed  to  assist  the  acquisition  management  team  in  gathering  the 
necessary  background  information.  Selected  delivery  media  options,  which  may  vary 
depending  on  the  specific  user's  requirements  (see  figure  10),  include;  (1)  Optic^  disk 
or  CD-ROM,  (2)  Magnetic  disk,  or  (3)  9-track  magnetic  tape,  ail  in  accordance  with  MIL- 
STD-1840. 


NOTE:  Paper  TMs  may  be  requested  in  addition  to  the  lETM  but  only  for  verification  of 
the  digital  data 
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4.8.1  Cost 


lETMs  should  be  built  on  a  solid  foundation  of  basic  logistics  technical  information 
(comprehensible,  valid,  appropriate  task  procedures;  accurate  configuration 
identification:  etc.).  Creating  and  maintaining  such  information  for  lETMs  is  a  major 
cost.  The  technology  to  author,  distribute,  and  use  lETMs  is  a  lesser,  largely  one-time 
cost.  Cost  Gu  laiysis  information  was  not  available  at  the  time  of  printing. 

4.8.2  CDRLs 

To  invoke  this  data  deliverable  option,  specific  TMCRs  and  CORLs  must  be  developed 
to  identify  the  type  of  TM  required  arid  include  language  that  specifies  exacOv  how  data 
will  be  delivered  under  the  contract  including  media,  format  (in  this  case  a  procassable 
text  data  file),  and  content.  To  invoke  this  data  deliverable  option,  specific  CDRLs  and 
TMCR  addendum  sheets  are  being  developed  as  examples  (not  available  at  the  time  of 
printing).  The  information  contained  in  the  following  contract  vehicles  should  be 
tailored  to  meet  the  requirements  of  the  specific  defense  system  program. 

4.9  Contractor  Validation 

The  contractor  should  be  required  to  validate  that  the  delivered  TM  conforms  to  the 
contractual  requirements.  Specific  validation  agenda  should  be  provided  in  the 
contractor's  validation  plan  and  associated  documentation. 

4.10  Government  Verification 

The  acceptance  of  CALS  digital  data  products,  either  delivered  on  physical 
media  or  by  CITIS,  is  different  in  several  ways  from  the  acceptance  of  comparable 
paper  data  products.  The  following  paragraphs  provide  details  on  the  acceptance  of 
digital  data  products  and  information  services. 

4.10.1  Digital  Data  Acceptance 

The  unique  aspect  of  CALS  digital  data  deliverables  is  that  they  will  be  subject  to 
inspection  and  acceptance  on  several  levels.  The  lowest  level  of  acceptance  is  the 
data  content  and  formal.  The  acceptance  process  at  this  level  is  identical  to 
acceptance  of  the  data  product  provided  on  paper.  This  level  of  acceptance  will  be 
accomplished  by  viewing  the  data  either  through  use  of  computer  video  screen  or  by 
vievwng  n  paper  printout  of  the  data  product. 

The  next  level  of  acceptance  is  adherence  to  the  specified  CALS  data  exchange 
format.  This  will  usually  be  compliant  with  the  CALS  standardization  documents  or 
other  national  or  international  data  exchange  standards.  This  level  of  acceptance  may 
be  aided  by  automated  tools  obtained,  if  available,  from  the  CALS  Test  Network  (CTN) 
or  each  service-component  CALS  office.  The  next  level  of  acceptance  is  applied  to  the 
MIL-STD-1840  digital  data  format  if  it  has  been  specified.  Again,  automated  tools  may 
be  used  to  verify  compliance.  Other  formatting  requirements  may  be  subject  to 
inspection  and  acceptance  including  X12  EDI  format,  when  specified. 

Finally,  the  physical  media  may  have  acceptance  criteria  to  be  applied.  This  level  of 
acceptance  will  not  be  used  if  data  has  been  formally  delivered  by  the  CI7iC  The 
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means  of  inspection  to  be  used  should  be  provided  to  the  contractor  as  soon  as  these 
means  have  been  determined.  Any  or  all  levels  of  acceptance  may  be  performed  at 
the  contractor's  facility  or  at  the  Government's  facility,  as  required.  In  addition  to  digital 
data  acceptance,  CITIS  requires  additional  acceptance  requirements  be  applied. 

4.10.2  CITIS  Acceptance 

Acceptance  of  the  service  and  the  CITIS  Contractor  Line  Item  Number  (CLIN),  if 
utilized,  is  a  verification  that  the  contractor  has  provided  the  service  as  specified.  The 
CITIS  functional  requirements  are  defined  by  MIL-STO-974(Draft)  and  the  particular 
statement  of  work.  A  checklist  of  CITIS  functional  requirements  may  be  prepared  to 
assist  in  tracking  contractor  compliance.  These  fijnc'*onal  requirements  may  include 
service  availability,  maintenance  response,  provision  for  core  information  fiinctions, 
provision  for  value-added  information  functions  and  the  like. 

Assurances  of  adequate  acceptance  testing  for  CITIS  should  be  obtained  via  contractor 
demonstration  of  the  service.  Tne  test  should  include  demonstration  of  functional 
capabilities  and  verification  that  the  CITIS  will  handle  data  required  to  be  formally 
delivered  through  CITIS  without  alteration  of  the  data  product.  Such  a  test  is  not 
required  for  each  delivery  but  may  be  rerun  if  major  maintenance  has  been 
accomplished  or  if  sending  or  receiving  systems  have  been  changed  enough  to  warrant 
an  additional  test.  If  specific  test  data  are  deemed  necessary  for  adequate  testing  of  a 
CITIS,  that  test  data  should  be  provided  and  results  reviewed  on-site  at  a  customer 
facility.  On-line  access  service  should  be  accepted  when  it  is  demonstrated  that  a 
person  with  proper  authorization  can  perform  the  contractually  required  core  and  value- 
added  functions  from  a  terminal  or  workstation  at  the  customer's  taciiity  or  as  otherwise 
agreed. 

Electronic  data  transfer  service  acceptance  should  occur  when  a  single  instance  of 
transfer  of  the  specified  deliverable  type  can  be  achieved  including  successful 
download  of  data  into  the  customer's  system  when  contractually  required.  This  data 
may  be  real  product  data  or  test  data,  as  appropriate. 
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FOREWORD 


Purpos* 


The  Navy  Ccmputer-aidad  Acquisition  and  Logistic  Support  (CALS)  Acquisition/ 
Impic.'nentation  Sub-Group  has  charged  the  CALS  Resource  ar>d  Implementation 
Cooperative  (RIQ  with  developing  acquisition  guidance  for  each  of  the  three  process 
architectures  defined  in  the  Navy  CALS  Architecturei/implementation  Plan.  This 
document  is  the  result  of  an  exhaustive  search  and  distillation  of  information  pertinent 
to  applying  CALS  to  the  creation,  managemenL  and  use  of  Logistic  Support  Artalysis 
(LS/^  process  and  LSA  data  The  purpose  of  this  document  is  to  aid  the  Navy/Marine 
Corps  Acquisition  Managers,  project  engineers,  and  project  logisticians  in  applying 
CALS  to  weapon  system  procurements  within  the  LSA  process. 

Scope 

The  three  process  architectures  described  in  the  Naval  Forces  CALS  Architecture  and 
Envirorunent  are: 

•  Engineering  Drawings 

•  Technical  Manuals  (TMs) 

•  Logistic  Support  Analysis  Record  (LSAR). 

This  document  has  been  revised  to  clarify  the  LSA  process  and  the  use  of  LSA  data 
This  document  revision  has  also  removed  the  appendix  that  contained  CALS 
terminology,  regulations,  specifications,  and  handbooks.  This  information  has  been 
corrsolidated  with  similar  infcxmation  removed  from  Technical  Data  Package  and 
Technical  Manual  documents  and  is  provided  as  an  appendix  of  the  Desktop  Guide. 

Overview 

Section  1.0,  introduction,  provides  a  brief  introduction  to  the  purpose,  scope,  and 
background  pertaining  to  CALS  arxl  the  LSA  process. 

Section  2.0,  LSA  and  LSAR  Introduction,  provides  a  brief  overview  of  LSA  and  LSAR. 

Section  3.0,  Current  Considerations,  provides  topics  of  consideration  that  must  be 
addressed  by  the  Acquisition  Manager  peruyning  to  the  application  of  CALS  initiatives 
to  the  LSA  process. 


Section  4.0,  Future  Considerations,  addresses  future  trends  and  issues  that  will  need 
to  be  taken  into  consideration  when  an  Acquisition  Manager  seeks  to  apply  CALS  to 
the  acquisition  of  LSA  data 
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1.0  INTRODUCTION 


Computer-aided  Acquisition  and  Logistics  Support  (CALS)  is  a  Department  of  Defense 
(DoD)  strategy  that,  when  fully  implemented,  will  enable  more  effective  creation, 
exchange,  and  use  of  digital  data  to  acquire  and  support  weapons  systems  and 
equipment  Logistics  Support  Artalysis  (LSA)  is  a  systematic  and  comprehensive 
anal^cal  process  that  is  conducted  on  an  iterative  basts  through  all  life  cycle  phases  of 
the  systern/equipment  LSA  is  for  quantifying  and  measuring  supportabiiity  ot^ectives 
[supportability  includes  ail  elements  of  integrated  Logistics  Support  (ILS)  as  defined  by 
the  Department  of  Defense  Instruction  (DoDO  5000.2  required  to  operate/maintain  the 
systerri/equipmenf). 

Depending  on  the  level  of  tailoring,  extensive  amounts  of  documentation  and  data  are 
required  as  an  input  to,  and  generated  as  a  result  of.  the  LSA  process.  The  LSA 
process  fits  into  the  ILS  process  as  LSA  tasks  are  planned,  irtitial  front  end  analyses 
are  performed,  and  LSA  reports  are  generated  (see  figure  1).  LSA  documentation 
consists  of  all  data  resulting  from  the  anitfysis  tasks  conducted  as  defined  in  MIL-STD- 
1388-1A  and  is  intended  to  be  the  primary  source  of  validated,  integrated,  desigiv 
related  supportability  data  pertaining  to  an  acquisition  program.  LSA  documentation  is 
developed  and  maintained  as  a  result  of  design,  support,  and  operational  concept 
development  and  is  updated  to  reflect  changes.  Changes  can  occur  because  of  the 
availability  of  better  information  from  testing,  configuration  changes,  operational 
concept  changes,  and  support  concept  changes  during  the  acquisition  process. 
Accumulated  LSA  documentation  and  data  provide  an  audit  trail  of  supportability  and 
supportabiiity-related  design  analyses  and  decisions.  They  are  the  basis  for  actions 
and  ILS  documents  related  to  manpower  and  personnel  requirements,  training 
programs,  provisioning,  maintenance  planning,  resource  aiiocation,  funding  decisions, 
and  other  logistic  support  resource  requirements.  LSA  Record  (LSAR)  data  is  a  subset 
of  LSA  documentation  and  is  a  structured  means  of  aggregating  LSA  data.  It  is 
available  for  use  by  all  services  and  ILS  element  functional  areas.  Because  the  LSAR 
database  is  structured,  it  has  become  the  primary  means  of  storing  logistics  data  on 
digital  media 
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FIGURE  1.  ILS  Process  Architecture 


1.1  Scope 


It  is  recognized  that  each  defense  system  program  is  unique  wHh  individual  constraints 
and  access  to  a  distinct  set  of  infrastructure  systems.  This  document  is  intended  to 
provide  the  Navy/Marine  Corps  Acquisition  Manager  with  an  overview  of  Navy  business 
practices  for  the  creation,  management,  and  use  of  LSA  data  in  a  CALS  environment 
Specific  implementation  of  this  process  may  be  further  tailored. 


1.2  Purpose 

The  purpose  of  this  document  is  to  provide  the  planning  for  the  creation,  management, 
and  use  of  LSA  data,  and  the  proliferation  of  this  data  through  the  ILS  element 
functional  areas.  These  areas  need  to  take  advantage  of  the  capabilities  provided  by 
the  automation  and  integration  capabilities  of  information  systems.  This  document  will 
correlate  and  identify  products  and  processes  within,  and  related  to,  specific  ILS 
functional  element  areas  that  either  input  data  to.  and/or  receive  data  from,  the  LSA 
process.  Digital  conduits,  those  areas  where  LSA  digital  data  can  be  directly  linked  to 
other  processes  or  products,  will  be  identified.  Common  data  used  where  current 
digital  linkage  is  not  available  will  also  be  identified. 

The  intent  of  this  document  is  to: 


Provide  an  overview  of  the  CALS  relationship  to  the  LSA  process  and  the 
development  of  LSA  data 

Describe  the  origins  of  data  used  as  input  to  the  LSA  process  in  a  CALS 


environment 

Describe  relationships  between  LSA  data  and  various  engineering  systems  and 
digital  tools  used  within  a  CALS  environment 

Describe  the  migration  of  LSA  data  to  various  ILS  element  functional  areas  and 
products  through  digital  application 
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•  Describe  life  cycle  consideration  relevant  to  LSA  and  CALS 

•  Describe  future  CALS  modernization  efforts  and  consideration. 

U  CALS  Introduction 

The  Department  of  Defense  (DoD)  CALS  strategy  is  designed  to  activeiy  promote  the 
digital  creation,  management,  artd  use  of  data  in  the  acquisition  and  sunx>rt  of  DoD 
systems.  CALS  is  not  a  single  system  but  rather  a  philosophy  that  emphasizes 
applications  of  standards  and  digital  sharing  of  data.  This  includes  the  data  generated 
the  LSA  process.  The  electronic  sharing  of  data  allows  the  data  to  be  created  once 
and  then  used  by  multiple  users,  multiple  times. 

lA  CALS  and  LSA  by  Functional  Activity 

Considerations  that  must  be  addressed  when  an  Acquisition  Manager  is  acquiring  LSA 
data  in  digital  format  include:  (1)  Spedficaiiy  who  will  use  the  data;  what  hardware 
and  software  are  needed  to  use  it;  will  the  digital  data  be  applied  directly  or  as 
source  information  for  the  follow-on  products;  (4)  are  there  digital  data  sources 
available  that  can  be  used  as  input  to  the  LSA  process  if  source  data  is  available,  who 
has  it  what  form  is  it  in,  and  is  there  any  problem  associated  with  providing  it?  These 
considerations,  to  various  degrees,  must  be  addressed  by  the  Acquisition  Manager  for 
and  within  each  of  the  three  ma^or  activities  (create,  manage,  and  use)  associated  with 
LSA  data  acquisition.  Rgure  2  Illustrates  some  of  these  considerations. 


FIGURE  2.  The  Three  Levels  of  Data  Activity 
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In  addition  to  activities  during  the  acquisition  phase  of  a  program  associated  with  the 
creation,  management,  and  use  of  LSA  daia,  the  Acquisition  Manager  must  also 
remain  aware  of  follow-on  Operational  and  Support  (O&S)  phase  needs  for,  and  uses 
of,  LSA  data.  Figure  3  illustrates  one  of  the  prinrij^es  of  Pareto's  Law  with  regards  to 
LSA  data  and  life-cycle  proportions.  Though  the  acquisition  phase  makes  up  only  a 
small  portion  of  the  program  life  cycle,  a  large  share  erf  LSA  activity  occurs  during  this 
period.  Conversely,  the  amount  of  LSA  activity  during  the  O&S  phase  is  considerably 
less  when  measured  against  the  activity  of  the  acquisition  phase.  The  use  of  LSA  data 
during  the  O&S  phase  is  applied  over  a  longer  period  of  time.  The  Acquisition  Manager 
should  ensure  that  the  LSA  process  not  only  impacts  and  records  the  design  of  the 
product,  but  also  Is  transferable  to  the  agencies  and  activities  that  will  ultimately 
support  the  design  during  the  O&S  phase. 


FIGURE  3.  LSA  Data  and  Activity  Compeuison  by  Phase 


1.4.1  LSA  Data  Creation  Activities 

The  first  level  of  activity  during  the  acquisition  phase  of  a  program  is  the  creation  of  the 
data.  The  Acquisition  Manager  is  the  primary  focal  point  during  the  creation  phase.  Of 
utmost  concern  to  the  Acquisition  Manager  is  the  assurance  that  the  data  is  developed 
once  and  then  used  many  times.  The  ability  to  review  and/or  access  LSA  data  by  all 
areas  involved  in  the  design  process  ensures  eariy  identification  and  quantification  of 
support  systems  requirements  as  well  as  the  best  design  for  supportabilty.  The 
Acquisition  Manager  must  ensure  that  the  internal  contractor  product  development 
team  members,  as  well  as  Government  reviewing  agencies,  have  access  to  current  and 
relevant  LSA  data 
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The  ability  to  access  and  review  digital  data  is  driven  by  the  availability  of  appropriate 
saftvrare  and  hardware.  The  Acquisition  Manager  should  ensure  all  functional  areas 
are  queried  for  software  and  hardware  availability  prior  to  contract  placement  Of  equal 
importance,  the  Acquisition  Manager  should  ensure  that  support  activities  are  aware  of 
LSA  riara  acoess,  review  and  approval  methodologies,  and  the  roles  and 
responsibilities  each  activity  will  play. 

1 .4J2  Follow>on  LSA  Data  Modification  Considerations 

In  addition  to  concerns  associated  with  the  creation  of  LSA  data,  the  Acquisition 
Manager  should  consider  future  requirements  to  modify  the  data  by  organic 
Goverrvnent  activities.  It  is  of  particular  importance  to  ensure  that  all  Front  End 
Arulyses  studies  and  reports,  as  well  as  the  LSAR  database,  are  provided  to  the  depot 
or  support  activity  in  a  usable  format  By  doing  this,  the  depot  and/or  support  acti^ 
will  be  provided  not  only  with  the  LSAR  database  that  supports  the  design,  but  also 
vrith  the  analyses  and  studies  used  to  arrive  at  the  design. 

1.4,3  LSA  Data  Management 

The  second  level  of  activity  is  associated  with  the  management  of  LSA  data  during  both 
the  acquisition  and  O&S  phases.  The  Acquisition  Manager  must  consider  the  specific 
Navy/K^ne  Corps  infrastructure  program  that  will  maruige  and  store  the  digital  data 
during  both  phases.  The  data  delivered  must  be  compatible  with  the  existing  digital 
Navy/Marine  Corps  system  in  place  or  being  developed,  if  char^ges  to  the  digital 
Navy/Marine  Corps  infrastructure  systems  are  required,  they  must  be  fully  justified  and 
coordinated  with  the  personnel  responsible  for  the  configuration  control  of  LSA  data. 
During  the  O&S  phase,  the  LSA  data  is  typically  assigned  to  a  support  activity  such  as 
a  Depot  Cognizant  Field  Activity  or  organic  Navy/Marine  Corps  Data  Repo^ory.  Of 
primary  importance  here  would  be  making  data  available  to  potential  users  and 
maintaining  configuration  control. 

1  .4j4  LSA  Data  Uses  During  the  Acqui^on  Process 

The  final  level  of  activity  is  associated  with  the  use  of  LSA  data.  During  the  Acquisition 
Process.  LSA  data  is  t^calty  used  in  three  ways.  FirsL  the  MIL-STD-1388-1A  Front 
Er  I  Analysis  'o,  noo  series  tasks  are  used  to  influence  and  provide  a  bas'-s  for 
the  '7''.  rf  the  system  (both  the  hardware  and  the  support  elements  required  for 
deployment  and  use).  Secondly,  the  LSAR  database  is  used  to  document  the  system's 
coagulation  and  maintenance/  support  requirements  and  procedures.  Finally,  the 
LSAR  database  is  used  as  a  cornerstone  for  the  developing  ILS  element  products  that 
include  provisioning  data,  technical  manuals,  training  data,  support  equipment  data, 
etc. 

Paramount  to  ILS  product  development  is  the  timely  access  to  current  and  accurate 
LSA  data.  The  following  are  just  a  few  of  the  considerations  the  Acquisition  Manager 
should  make  when  contracting  for  LSA  data 

•  Technical  Manuals  (TMs):  The  LSAR  mairrtenance  tasks  (LSA-401)  should  be 
used  as  a  basis  for,  and/or  a  direct  input  to  the  system's  TM(s).  The  Acquisition 
Manager  should  ensure  that  the  development  of  the  TM(s)  and  the  detailed  LSA 
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task  analysis  are  orchestrated  in  such  a  marvier  as  to  eliminate  duplicate 
efforts.  One  potential  problem,  which  somewhat  limits  the  effectiveness  of 
authoring  the  TM  within  the  confines  of  the  LSAR  database,  is  the  Standard 
Generalized  Markup  Language  (SGML)  tagging  requirements  necessary  for 
CALS-compliant  TMs.  Several  approaches  including  embedding  the  SGML  tags 
within  the  LSAR  database  itself  or  'Ottering*  the  text  as  it  is  imported  into  the  TM 
author/editing  environment  offer  potential  solutions. 

•  Training  Data  The  training  functional  area  takes  information  from  the  LSAR 
database  and  uses  it  as  source  data  to  develop  the  Navy  Training  Plan  (IJTP) 
and  various  other  training  products.  An  imoortant  CALS>related  consideration 
would  be  to  provide  the  training-related  LSA  source  data  to  the  training  area  in  a 
usable  digital  formal 

•  Provisioning:  Supply  support  and  initial  provisioning  efforts  take  direct 
advantage  of  the  data  contained  within  the  LSAR  database.  The  Acquisition 
Manager  should  coordinate  the  availability  of  the  LSAR  database  vrith 
provisioning  efforts. 

•  Support  Equipment  (SE):  Support  Equipment  Recommendation  Data  (SERD) 
information  is  typically  generated  during  tfie  LSA  process  and  documented 
within  the  LSAR  database.  The  Acquisition  Manager  should  coordinate  LSAR 
access  and  delivery  with  SE  Logistics  Element  Manager  (LEM). 

1.4.5  LSA  Data  Uses  During  the  O&S  Phase 

A  major  concern  to  the  Acquisition  Manager  is  th^  usefulness  of  the  LSA  data  during 
the  O&S  phase  of  a  program.  The  Acquisition  Manager  should  ensure  that  both  LSA 
Front  End  Analysis  data  and  the  LSAR  database  are  made  available  and/or  maintained 
by  the  support  activity  for  both  configuration  control  and  evaluation  of  potential 
Engineering  Change  Proposals  (ECP)  during  the  O&S  phase. 

One  additional  area  of  consideration  concerns  the  end  users.  The  end  users  perform 
an  important  feedback  function  in  the  LSA  process.  Knowledge  of  actual  usage  of  the 
data  when  fed  back  into  the  LSA  process  is  irtvaluable  in  correcting  design  and  support 
system  deficiencies.  The  Acquisition  Martager  must  not  overlook  this  vital  source  of 
data  and  should  consider  the  end  users  when  acquiring  digiu  I  data  and  feedback 
methodologies. 

in  conclusion,  the  Acquisition  Manager  must  include  in  the  decision  making  the 
hardware  and  software  that  exists  at  all  user  sites  being  considered.  it  is 
counterproductive  to  generate  and  make  availat^e  to  the  end  users  digital  data  that 
they  do  not  have  the  capability  of  using.  The  Acquisition  Martager  cartnot  assume  the 
systems  exist  and  will  be  used.  The  specific  environment  must  be  determined. 

1.5  CALS-Related  Questions 

Questions  that  must  be  asked  and  answe;  cd  include; 

•  What  systems  are  available  in  the  fieid  and  at  support  activities? 

•  How  is  the  data  to  be  used  by  the  field/support  activities? 
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•  For  specific  users,  what  data  media  and  formats  are  compatible  with  what  they 
airea^  have  or  are  planning  to  acquire? 

•  How  will  they  acquire  the  new  equipment  and  software  needed  if  existing 
systems  are  inadequate? 

•  How  will  these  rtew  systems  be  supported? 

The  answers  to  these  and  similar  questions  wilt  provide  a  comprehensive  plan  for 
implementing  and  using  the  digital  data  that  is  acquired.  The  answers  are  dependent 
on  the  irxtividual  users  in  the  specific  acquisition  program. 
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2.0  LSA  AND  LSAR  INTRODUCTION 


The  integrated  Logistics  Support  (ILS)  goal  is  an  organized,  planried  effort  that 
provides  for  support  and  maintenance  considerations  that  influence  the  design  of 
systems  acquired  by  the  DoD.  The  planning  of  the  ILS  effort  is  key  in  fitting  all  of  the 
logistic  support  eiem«‘nts  together  in  a  tim^  manner.  The  LSA  process  ties  the  ILS 
efforts  tog^er  following  the  full  life  cycle  of  the  end  item  (figure  4). 
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FIGURE  4.  ILS  and  LSA  Planning  Process 


The  LSA  process  is  a  planned  series  of  tasks  performed  to  examine  all  elements  of  a 
proposed  system  to  determine  the  logistic  support  required  to  keep  that  system  usable 
for  its  intended  purpose  and  to  influence  ^e  design  so  that  both  the  system  and 
support  can  be  provided  at  an  affordable  cost  The  LSAR  is  a  subset  of  LSA  data  that 
resides  in  an  approved  format  in  an  approved  database  system  (figure  5). 
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FIGURE  5.  ILS/LSA/LSAR  Relationship 

ILS  may  be  presented  in  any  form  or  characteristic  including,  but  not  limited  to, 
hard  copy,  audio/visual  displays,  magnetic  tape,  disc,  and  other  electronic  metSa  ILS 
data  normally  consists  of  plans,  reports  and  analyses  performed  in  support  of 
development,  deployment,  and  support  of  a  specific  d^ense  system.  ILS  data  will  be 
created  in  a  prooessable  data  format  consisting  primarily  of  text 

An  ILS  program  interfaces  with  and  produces  processable  data  related  to: 

•  Maintenance  Planning 

•  Manpower  and  Personnel 

•  Supply  Support 

•  Support  Equipment 

•  Technical  Data 

•  T raining  and  T raining  Support 

•  Computer  Resources  Support 

•  Faculties 

•  Padraging,  Handling,  Storage,  and  Transportation 

•  Design  Interface 
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2.1  LSA  Summary 

LSA  documentation,  including  data  in  the  LSAR  database,  is  generated  as  a  result  of 
the  analysis  tasks  specified  in  MIL-STD-ISSS-IA  As  such,  the  LSAR  database 
(created  as  a  processable  database)  shall  serve  as  the  center  of  the  ILS  technical 
support  database,  vrhich  can  interface  with  material  acquisition  programs  to  satisfy  the 
support  acquisition.  The  specific  data  entry  media,  storage,  and  maintenance 
procedures  are  left  to  the  performing  activity. 
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2Jl  LSAR  Summary 

MIL-STD-1388-2A/2B,  "OoD  Requirements  for  a  Logistic  Support  Analysis  Record* 
(LSAR),  contains  general  requirements  and  defines  the  data  elements,  data 
record/tabie  formats,  output  report  formats  and  guidance  for  tailoring  the  LSAR  to  a 
particular  application.  Simply  puL  the  LSAR  is  that  portion  of  the  LSA  documentation 
consisting  of  the  detailed  data  pertaining  to  the  identification  of  Logistics  Support 
requirements  of  a  system  or  equipment.  MIL-STD-1388-2A/2B  is  nothing  more  than  the 
database  where  a  portion  of  the  LSA  documentation  Is  stored.  The  LSAR  is  not  an  end 
product  but  is  intended  to  be  used  and  updated  throughout  the  acquisition  life  cycle  of 
the  system  or  equipment 

MIL-STD-1388-2A  was  superseded  by  MIL-STD-1388-2B  in  March  of  1991.  MIL-STD- 
1388-2A  is  mentioned  because  there  are  many  programs  currently  in  effect  that  are 
required  to  deliver  data  in  the  MIL-STD-1388-2A  format  MIL-STD-1388-2B  replaces 
the  Hollerith  80>column  card  approach  of  •2A  with  an  integrated  database  employing 
current  industry>developed  relational  database  technology. 

Although  many  of  the  data  elements  are  the  same  in  2A  and  2B,  many  are  different 
To  go  from  to  2A  to  2B  is  not  a  simple  task.  The  transfer  of  data  from  the  flat  file  2A 
database  to  the  relational  tables  of  the  2B  database  is  not  a  transparent  upgrade  of 
LSAR  database  software.  If  an  item  is  being  modified  and  an  LSAR  database  already 
exists  as  a  2A  database,  the  Acquisition  Manager  should  consider  the  benefits  gained 
when  going  to  a  2B  database,  if  the  benefits  are  minimal,  modify  the  2A  database.  A 
new  acquisition  program  should  use  the  MIL-STO-1388-2B  LSAR  database.  Validated 
LSAR  .Automated  Data  Processing  (AOP)  systems  are  available  for  automated  storage 
of  the  LSA  data  A  list  of  these  LSAR  ADP  systems  may  be  obtained  from  the  USAMC 
Material  Readiness  Support  Activity  (MRSA),  ATTN:  AMXMD-EL,  Lexington,  KY 
40511-5101.  The  following  two  subsections  discuss  the  two  versions  of  LSAR 
databases  in  more  detail. 

2^1  MIL-STD-1388-2A  Summary 

MIL-STD-1388-2A  prescribes  the  data-element  definitions,  data-field  lengths,  and  data- 
entry  requirements  for  the  LSAR  database.  It  identifies  the  reports  that  are  generated 
from  the  LSAR  database  and  identifies  the  input  formats  for  the  Joint  Service  LSAR 
AOP  system  'hen  it  is  i  ’  ■  standard  applies  to  all  system/equipment  acquisition 
programs,  m:^  ".jr;  ication  programs,  and  applicable  research  and  development 

projects  through  all  phases  of  the  system/equipment  life  cycle.  The  logistic  support 
analysis  process  is  conducted  on  an  iterative  basis  through  all  phases  of  the 
system/equipment  life  cycle  to  satisfy  the  support  analysis  objectives.  During  the 
acquisition  phase,  the  contractor  would  normally  perform  the  LSA  process.  After  the 
transition  to  the  organic  support  phase,  the  Navy/Marine  Corps  would  continue  the  LSA 
process.  Similarly,  LSA  data  are  generated  in  all  phases  of  the  system/equipment  life 
cycle  and  is  used  as  input  to  follow-on  analyses  and  as  an  aid  in  developing  logistics 
products.  LSA  data  and  documentation  are  generated  as  a  result  of  MIL'STD-1388-1 A. 
As  such,  the  LSAR  database  shall  serve  as  the  integrated  logistic  support  technical 
database  applicable  to  all  material  acquisitions  programs  to  satisfy  the  acquisition  of 
support  resources.  The  specific  data  entry  media,  storage,  and  maintenance 
procedures  are  ieft  to  the  performing  activity. 
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2^^  MIL-STD-1388-2B  Summary 


MIL-STD-1388-2B  contains  10  relational  table  areas,  which  are  further  divided  into  104 
individual  data  tables.  The  new  MIL-STD-1388-2B  will  satisfy  a  wider  range  of  logistic 
product  requirements  and  promote  the  use  of  relational  database  management 
systems  for  LSAR  automated  data  processing  (ADP)  systems.  Just  like  MIL-STD-1388- 
2A,  MIL-STD>1388-2B  provides  information  pertaining  to  technical  characteristics  of  a 
system  or  equipment  and  provides  data  directly  related  to  the  supportabillty  of  that 
system  or  equipment 

MiL-STD-1388-2B  Appendix  A  provides  guidance  for  fulfilling  the  requirements  of  a 
relational  database  system.  Although  each  relational  table  is  indepen^nt  and  equal, 
data  integrity  rules  will  dictate  that  a  row  of  information  be  established  in  a  table  from 
which  foreign  keys  originate  prior  to  establishment  of  the  lower-tiered  data  table.  The 
interrelationships  and  data  hierarchy  among  tables  are  established  only  through 
common  data  element  keys  and  data  values.  MIL-STD-1388-2B  provides  the  media 
options  of  the  LSAR  relational  tables  being  delivered.  This  provides  the  capability  to 
subsequently  produce  any  of  the  LSA  reports,  other  data  files,  and  ad  hoc  reports  via 
the  query  capability  of  a  validated  LSA  relational  ADP  system. 
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3U)  CURRENT  CONSIDERATIONS  FOR  THE  LSA  PROCESS  IN  A  CALS 
ENVIRONMENT 

System  acquisition  and  ILS  policies  are  contained  in  DoOl  5000.2.  The  four  prime 
factors  that  govern  system  acquisition  programs  are  cost,  schedule,  performance,  and 
supportability.  The  LSA  process  provides  direct  input  into  the  supporta^lity  and  cost 
factors  associated  with  a  systern/equipmerrt  and,  therefore,  provides  significant  input 
into  system/equipment  decisions.  The  CALS  environment  offers  the  opp(»timity 
through  digital  application  of  the  LSA  process  for  reductions  in  Life  Cyde  Cost  (LCC). 
The  ability  to  create  data  once  (including  LSA,  engineering,  and  ILS  data)  and  use  it 
many  times  impacts  the  cost  of  the  LSA  process  and  the  follow-on  support  costs.  If  the 
LSA  data  and  associated  analysis  (FMECA,  RCM,  etc.)  is  created  in  a  digital  formaL 
then  digital  data  required  for  the  LSA  can  be  linked  and  fed  to  the  LSAR  database  in  an 
automated  fashion.  The  initialiy  created  LSA  data  is  then  available  for  use  in  aN 
technical  data  products.  The  Acquisition  Manager  must  consider  the  digital  format, 
media,  HW/SW  issues,  required  framework,  architecture,  and  infrastructure  when 
making  LSA  process  decisions  in  the  procurement  phase  (figure  6). 


FIGURE  6.  CALS  and  the  LSA  Process 


As  an  alternative,  the  Acquisition  Manager  could  place  the  responsibility  for  digital  data 
considerations  on  the  contractor  in  the  Request  for  Quotes/Request  for  Proposals 
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(RFQ/RFP).  MIL-STD-1388-2B  is  required  for  ali  new  procurements.  Also,  the 
instructions  to  offerers  couid  indicate  that  the  digital  application  of  LSA  data  will  be 
weighted  strongly  in  the  evaluation  of  the  offerers"  CALS  Implementation  Rans 
(CALSIPs). 

3.1  Populating  the  LSA  Database 

3.1.1  Potential  Sources  of  LSA  Data 

The  digital  application  of  data  must  start  with  the  onset  of  the  LSA  process.  Acquisition 
Managers  should  begin  by  providing  Goverrvnent  Furnished  Information  (GFI), 
including  the  LSA  strategy  and  ILS  planning  information,  in  digital  form  to  the 
contractor.  Digitizing  these  products  will  help  reinforce  the  Government  commitment  to 
CALS,  as  well  as  reduce  costs  aruf  improve  communications.  Rgure  7  represents 
potential  sources  and  the  flow  of  information  into  the  LSA  process. 


FIGURE  7.  Data  Row  of  the  LSA  Process 

Populating  the  LSAR  database  can  be  aided  by  a  well  defined  LSA  Plan  (LSAP).  The 
Acquisition  Manager  should  require  that  this  plan  define  not  only  who  in  the 
Contractor's  organization  is  responsible  for  generating  and  receiving  LSA  source  data, 
but  also  in  what  form  the  data  should  be  developed,  and  how  the  Contractor  plans  to 
import  this  data  into  the  LSAR  database.  Populating  the  LSAR  database  would  be 
simplified  if  the  LSA  data  existed  in  a  digital  format  and  data  needed  could  be  easily 
extracted  for  input.  The  amount  of  preparation  and  maintenance  of  the  LSAR 
database  is  directly  related  to  the  connplexity  of  the  hardware  and  software  end  item 
design. 

3.2  Managing/Maintaining  LSA  Data 

The  Acquisition  Manager  will  decide  whether  the  weapon  system's  data  will  be 
maintained  under  a  Contractor  Integrated  Technical  Information  Senrice  (CITIS) 
arrangement  or  other  digital  means  of  delivery  to  the  Government.  In  either  event,  the 
decision  process  in  determining  the  LSA  data  required  will  be  the  same. 
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Considerations  must  be  made  that  encompass  ail  life-cyde  phases  from  design  to 
disposal.  The  Acquisition  Manager  must  be  aware  of  the  infrastructure  systems 
available  that  will  be  impacted  and  possibly  use  the  LSA  digital  data  created.  The 
Acquisition  Manager  must  keep  abreast  of  Navy/Marine  Corps  programs  that  may 
create  and/or  use  LSA  data  such  as  Joint  Engineering  Data  Management  and 
Information  Control  System  (JEOMICS),  Ship  Configuration  and  Logistic  Support 
Information  Sen/ice  (SCLSIS),  Computer-Aided  Design  (Second  Acquisition)  (CAD-2) ^ 
etc. 

3^  Using  LSA  Data  in  the  CALS  Environment 

This  section  will  focus  on  the  current  capabilities  of  CALS  to  employ  and  use  the  data 
that  exists  In  the  LSA  database.  Distinctions  between  MIL-STD-138^2A  and  MIL-STD- 
1388-2B  win  be  discussed  only  where  relevant  to  digital  data  interactioa  Emphasis  wHI 
be  placed  on  aeating  the  data  once  and  using  it  many  times.  The  unique  e^cts  of  a 
shared  digital  environment  on  the  current  use  of  the  LSAR  database  wiU  be 
investigated  and  discussed. 

3.3.1  CALS  Effects  on  LSAR  Report  Requirements 

In  the  past  the  completeness  and  accuracy  of  the  data  has  typically  been  verified  by 
the  contractor  demonstrating  the  ability  to  produce  various  output  reports  from  the 
LSAR  database.  The  Acquisition  Manager  is  encouraged  to  shift  emphasis  from  the 
delivery  of  the  LSA  reports  to  the  delivery  of,  and/or  preferably  the  access  to,  the  LSAR 
database  itself,  in  doing  this,  the  verification  of  the  database  and  its  accuracy  and 
completeness  can  be  more  easily  and  accurately  assessed.  However,  prior  to  using 
this  approach,  the  Acquisition  Manager  must  ensure  that  HW/SW  is  in  place  to  accepL 
process,  and  validate  the  LSA  data 

3.3.2  Interaction  of  LSA  Data  with  Concurrent  Engineering/Integrated  Design 

The  LSA  process  is  iterative  in  nature.  The  LSAR  database  provides  a  structured, 
standardized,  yet  flexible/taiiorable  approach  to  the  documentation  of  the  data  that 
results  from  accomplishing  various  LSA  tasks.  As  such,  the  LSA  process  is  an 
effective  toot  to  aid  in  the  application  of  concurrent  engineering  initiatives.  To  be 
effective,  LSA  documentation  must  be  initiated  early  in  the  acquisition  life  cycle,  must 
be  updated  to  reflect  changes  in  the  hardware  design  and  support  concept,  and  must 
be  tailored  to  be  commensurate  with  individual  program  requirements,  constraints,  and 
characteristics.  This  is  consistent  with  concurrent  engineering/integrated  design  as  all 
life-cycle  support  considerations  are  being  considered  at  each  phase  of  the 
development  process. 

3.3.3  Specific  CALS  Considerations  Affecting  Data  Acquisition 

During  the  analysis  of  the  supportabiiity  portion  of  the  LSA  process,  LSA  data  is  used 
as  direct  input  into  the  development  of  data  products  associated  with  ILS  elements 
such  as  provisioning  lists,  personnel  and  training  requirements,  and  TMs.  This  assures 
compatibility  among  ILS  element  documents  and  permits  common  use  of  data  that 
apply  to  more  than  one  logistic  element.  The  CALS  infrastructure  available  to  the 
Acquisition  Manager  when  he  is  ready  to  issue  an  RFQ/RFP  must  be  considered. 
Delivery  of  the  LSA/LSAR  data/database  may  be  via  digital  media  (magnetic  or  optical 
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media)  or  must  be  made  available  under  a  cms  requirement  The  media  selected  will 
be  driven  by  factors  including  infrastructure  arid  data  access  needs. 

3  J.4  Migration  of  LSA  Data  into  ILS  Element  Products 

For  the  proper  migration  of  LSA  data  to  be  compiets  and  full  support  of  afl  ILS  element 
products,  the  concurrent  engineering  cortcept  must  also  be  implemented.  The 
Acquisition  Manager  must  task  the  contractor  to  support  the  movwnent  of  LSA  data  into 
the  design  process  through  the  use  of  ILS  element  products.  The  LSA  process  and 
LSA  data  captured  must  take  into  account  the  function  of  the  system  under  design. 
The  LSA  data  and  resulting  LSAR  database  must  support  artd  be  used  as  input  data  to 
various  ILS  elements  irtcluding  the  NTP.  support  equipmenL  facilities,  supply  support 
manpower  and  personnel  lists,  envirorvnentai  impi^  parts  control,  and  so  on.  It  is 
essential  that  coordination  and  intarfedng  of  engineering  disciplirws  and  ILS  functional 
elements  be  effected  to  maximize  the  usage  of  data  developed  by  each  program 
element  thereby,  realizing  analysis  economics  amd  avoidhig  the  generation  of 
incompatible  ILS  products.  Again,  we  want  to  create  the  data  once  and  use  it  multiple 
times.  Figure  8  depicts  the  migration  of  LSA  data  into  the  ILS  element  products. 

It  is  important  to  identify  the  engineering  and  ILS  functiortai  element  requirements  that 
interface  with  the  LSA  process  and  generate  LSA  data,  Results  of  analyses  from  other 
program  elements  can  be  used  as  soiace  data  for  LSA  tasks  and  vice  versa,  inputs 
from  the  design,  reliability  and  maintainabiiity,  human  engineering,  safety,  LCC,  and 
other  program  elements  are  generally  required  to  satisfy  the  requirements  of  MIL-STD> 
1388-1A.  Benefits  of  effective  interfacing  and  coordinaticm  may  also  be  achieved  by 
utilizing  the  features  of  the  LSAR  database  to  record,  store,  and  manipulate  data  in 
support  of  requirements  levied  by  other  program  elements. 


FIGURE  8.  Migration  of  LSA  Data  into  ILS  Bemerrts 


3.4  CALS  Effects  on  Systems  &  Support  Systems  Designs 

Weapon  systems  acquisitions  are  directed  toward  achieving  the  best  balance  among 
cosL  schedule,  performance,  and  supportabiiity.  There  is  increasing  awareness  that 
supportabiiity  factors  such  as  manpower  and  personnel  skills  are  a  critical  eiemerrt  in 
sy^em  effectiveness.  This  awareness  has  necessitated  early  support  analyses  and 
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the  establishment  of  system  constraints  and  design  goals.  The  awareness  has 
necessitated  the  pursuit  of  design,  operational,  and  support  approaches  that  optimize 
life-cycle  costs  and  the  resources  required  to  operate  and  maintain  systems.  The 
Acquisition  Manager  should  encourage  the  use  of  Navy/Marine  Corps  CALS 
infrastructure  modernization  programs  such  as  Advance  Technical  Irrformation 
Support/lnteracti''«!  Electronic  Technical  Manuals  (ATIS/IETM)  to  enhance  the 
supportability  factors  of  systems  and  support  system  designs.  Both  cost  and 
performance  may  be  improved  using  digital  application  of  technical  information. 

33  Sample  CALS  &  LSA  Tasks  Statement  of  Work 

When  requesting  MIL-ST0-1388-1A  LSA  tasks  in  an  RFQ/RFP  Statement  of  Work 
(SOW),  specific  requests  for  CALS  should  be  included.  During  the  tailoring  process  of 
LSA  tasks,  the  Acquisition  Manager  should  request  the  contractor  to  include  the  impact 
of  CALS  when  performing  the  task. 

3.5.1  MIL-STD-1385-1A 100  Series  Tasks 

The  primary  purpose  of  the  100  Series  LSA  tasks  of  MIL-STD-ISSS-IA  is  the 
management  and  control  of  the  LSA  program.  The  Acquisition  Manager  should  include 
CALS  as  a  factor  when  performing  Task  101,  Development  of  an  Early  Logistics 
Support  Analysis  Strategy,  when  deciding  which  of  the  LSA  tasks  and  subtasks  will 
provide  the  Government  with  the  best  return  on  investment  The  following  statement 
may  be  included  in  the  SOW  when  requesting  a  contractor  to  perform  Task  102  of  MIL- 
STD-1388-1A: 

The  contractor  shall  include  as  part  of  Task  102,  Logistics  Support  Analysis 
Plan,  a  description  of  how  CALS  (the  digital  management  and  flow  of  data)  is 
being  integrated  into  the  LSA  tasks  and  shall  identify  how  CALS  will  be  used  in 
interfacing  the  data  developed  from  the  LSA  process  with  other  ILS  and  system- 
oriented  tasks  and  data.* 

3.5.2  MIL-STD-1385-1A  200  Series  Tasks 

The  200  Series  LSA  tasks  of  MIL-STD-1388-1A  are  to  establish  supportability 
objectives  and  supportability-related  design  goals,  thresholds  and  constraints  through 
comparison  with  existing  sterns  and  analyses  of  supportability,  cost  and  readiness 
drivers.  CALS  should  be  included  as  part  of  the  ot^ectives,  considerations,  and 
comparisons.  The  following  statements  may  be  included  in  the  SOW  when  requesting 
a  contractor  to  perform  one  of  the  200  Series  LSA  tasks  of  MIL-STD-1388-1 A  in  which 
CALS  should  be  considered: 

The  contractor  shall  perform  Task  201,  Use  Study,  to  identify  and  document 
the  pertinent  supportability  factors  related  to  the  intended  use  of  the  (name  of 
new  system  or  equipment).  This  study  shall  include  the  contractor's  intended 
use  of  CALS  as  one  of  the  pertinent  supportability  factors.* 

The  contractor  shall  perform  Task  202,  Mission  Hardware,  Software,  and 
Support  Standardization,  to  provide  supportability  and  supportability-related 
design  constraints  for  the  (name  of  new  system  or  equipmerrt)  based  on  existing 
and  planned  logistic  support  resources  that  have  benefits  due  to  cost, 
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manpower,  personnel,  readiness,  or  support  policy  considerations  and  benefits. 
Identification  of  existing  and  planned  logistics  support  resources  shall  include 
CALS  as  one  of  the  potential  benefit  factors  to  be  considered." 

The  contractor  shall  perform  Task  203,  Comparative  Analysis,  to  select  or 
develop  a  Baseline  Comparison  System  (BCS)  representing  characteristics  of 
the  (name  of  new  system  or  equipment.  This  aruriysis  shaN  irtclude  any  past 
CALS  implementation  of  the  d^gn  and  support  of  the  existing  system.  The 
analysis  may  be  a  factor  in  which  judgments  can  be  made  in  determining  the 
feasibility  of  the  supportability  parameters.  This  analysis  shall  also  iridude  the 
identification  of  areas  for  improvement  in  which  CALS  may  be  targeted." 

"The  contractor  shall  perform  Task  204,  Technological  Opportunities,  to  identify 
and  evaluate  design  opportunities  for  improvement  of  supportability 
characteristics  and  requirements  of  the  (name  of  new  system  or  equipment). 
These  opportunities  shall  consider  implementation  of  CALS  into  the  design 
ot^ectives  and  techniques.  The  iden%  of  CALS  implementation  in  design 
improvements  to  logistic  elements  during  development  should  also  be 
considered." 

3^^  MIL-STD-1383-1A  300  Series  Tasks 

The  300  Series  LSA  tasks  of  MiL*STD-1388-1A  are  to  optimize  the  SL^port  system  for 
the  new  item  and  to  develop  a  system  that  achieves  the  best  balance  among  cost, 
schedule,  performance,  and  supportabiiity.  CALS  should  be  considered  as  part  of  the 
functional  requirements  and/or  a  support  system  aitemalive.  The  following  statements 
may  be  included  in  the  SOW  when  requesting  a  contractor  to  perform  one  of  the  300 
Series  LSA  tasks  of  MIL-STD-1388-1  A. 

"The  contractor  shall  perform  Task  301,  Functional  Requirements  identification, 
to  identify  the  operations,  mairrtenance,  and  support  functions  that  must  be 
performed  in  the  intended  envirorunent  for  each  (name  of  new  system  or 
equipment)  alternative  under  consideration.  The  idei^cation  shall  include  the 
corrtractor's  intended  use  of  CALS  as  one  of  these  functional  requirements." 

"The  contractor  shall  perform  Task  302,  Support  System  Alternatives,  to 
establish  viable  support  system  alternatives  for  the  (name  of  new  system  or 
equipment).  The  contractor  shall  include  support  concepts  that  foster  CALS 
utilization  when  developing  alternatives  to  the  s^em  level  support  concept." 

The  contractor  shall  perform  Task  303,  Evaluation  of  Alternatives  and  Tradeoff 
Analysis,  to  determine  the  preferred  support  system  attemative(s)  for  each 
(name  of  new  system  or  equipment)  aitemative.  For  each  evaluation  and 
tradeoff  to  be  conducted  under  this  task,  the  contractor  shall  include  the 
utilization  of  the  intent  of  CALS  as  one  of  the  criteria  of  evaluation." 
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4.0  FUTURE  CONSIDERATIONS  FOR  THE  LSA  PROCESS  IN  A  CALS 
ENVIRONMENT 

While  section  3.0  presents  practical  observations  about  the  current  effects  of  CALS  on 
the  acquisition  of  LSA  data,  this  section  will  present  some  thoughts  on  where  CALS  is 
headed  and  how  that  might  affect  data  use  in  the  future.  The  influence  of  infrastructure 
developments  in  the  Navy,  witNn  the  OoO.  and  even  in  the  intematioruiJ  commur%  will 
all  affect  the  potential  environment  in  which  the  LSA  data  acquired  now  m^  have  to  be 
used  in  the  future. 

4.1  Integrated  Weapon  Systems  Database  (IWSDB) 

4.1.1  Future  Trends 

Future  trends  must  lead  to  arKi  support  the  fundamental  objective  of  CALS,  which  is  to 
lower  costs  to  the  Government,  improve  quality,  and  shorten  lead  tiiiies.  The  eiectronic 
sharing  of  data  allows  it  to  be  created  once  and  then  used  by  multiple  users,  multiple 
times.  The  integration  of  functional  processes  will  start  with  the  integration  of  data. 
The  acquisition  strategy  must  spedficaliy  address  the  automation  and  integration  of 
technical  information  sy^ems  and  functional  processes. 

4.1.2  Effects  on  LSA  Data  and  LSAR  Databases 

The  process  for  determining  LSA  data  and  LSAR  database  requirements  is  an 
extension  of  the  process  currently  used  for  determining  data  requirements,  selecting 
appropriate  data  items,  and  developing  the  Contract  Data  Requirements  List  (CDRL) 
that  identifies  the  requirements.  The  LSA/LSAR  databases  are  the  building  blocks  that 
are  necessary  to  support  an  IWSDB.  The  process  for  determining  LSA  data  and  LSAR 
database  requirements  may  evolve  as  the  requirement  for  access  to  the  data 
intensifies.  There  is  significant  poterrtiai  for  reduction  of  data  requirements  in  that  with 
query  capability,  the  Government  can  generate  data,  reports,  and  products  on  demand 
rather  than  having  the  contractor  prepare  and  deliver  them.  As  digital  data  utiliiation 
evolves,  the  media  on  which  the  data  is  delivered  also  evolve  as  depicted  on  figure 
9. 
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FIGURE  9.  IWSDB  Future  Influence  on  ILS  Data 
4^  Contractor  integrated  Technical  Information  Service  (CmS) 

4^.1  Future  Trenda 

Access  to  digital  data  will  become  the  standard  by  which  all  acquisitions  will  be 
measured.  Because  CUIS  provides  access  to  contractor-managed,  functionally- 
integrated  information,  it  must  play  a  significant  role  in  improved  Government 
operations  and  the  streamlining  of  processes.  An  effective  CITIS  program  will  require 
foresight  and  added  coordination  efforts  on  the  part  of  contractors.  Government 
sponsors,  and  potential  CITIS  users.  Functional  integration  approaches,  as  well  as 
CmS  perfrvmance,  must  be  considered.  Measures  should  be  developed  to  motivate 
contractors  with  top-level  commitments  to  produce  overall,  functional  integration  and  an 
effective  CITIS  implementation. 

4.2.2  Effects  on  LSA 

An  effective  LSA  program  will  be  planned,  integrated,  developed,  and  conducted  in 
conjunction  with  the  requirements  of  the  overall  acquisition  program  objectives.  The 
LSA  process  will  be  established  consistent  with  the  type  and  phase  of  the  acquisition 
program.  To  maximize  the  use  of  the  plans,  procedures,  front-end  analyses  and 
reports  developed  from  selected  LSA  tasks,  it  is  necessary  to  establish  a  viable 
communication  link  with  the  contractor.  Providing  an  early-on  CITIS  capability 
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(including  the  front-end  analyses  and  documentation  generated  from  the  200  &  300 
series  tasks  of  MIL- STD- 1388-1 A)  will  enhance  the  LSA  process  and  the  overall  design 
effort 

4^.3  Effects  on  LSA  Databases 

There  are  several  considerations  facing  contractors  when  they  are  tasked  with 
providing  CITIS  to  support  LSA  databases.  Areas  of  consideration  include  the 
following. 

•  Type  of  DBMS  or  languages;  The  numbw-  and  disparity  among  database 
management  systems,  programming  languages,  data  models,  data  descriptions 
or  data  organizatiorrs,  and  interface  and  access  languages; 

•  Data  element  fonrtat  The  number  of  discrete  techruques  for  reformatting  data 
to  be  presented  to  the  user  in  a  predefined,  standard  format  including 
conversion  of  units  of  measure,  translation  into  standard  format,  and  other 
agreed  upon  translations  or  conversions; 

•  Source  or  location  of  data  and  applications;  The  user  must  know  the 
differences  concerning  location,  hardware,  operation  system,  programming 
language,  and  access  methods  for  specific  systems; 

•  Relationship  and  dependencies;  The  degree  to  which  the  user  must  keep  track 
of  data  relationships  and  dependencies  within  and  across  integrated  data  sets; 

•  Version  knowledge  and  control;  The  degree  to  which  the  user  must  ensure  that 
data  retrieved  from  mae  than  one  system  and  database  are  consistent  In  terms 
of  data  values,  version  or  status,  and  context 
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5.0  SUMMARY  AND  CONCLUSIONS 


As  stated  in  the  introduction  to  this  document,  CALS  is  a  DoO  strategy  that  will  enable 
more  effective  creation,  exchange,  and  utilization  of  digital  data.  The  underlying 
purpose  of  this  strategy  is  to  move  from  a  paper-intensive  environment  to  a  digital 
environment  in  an  effort  to  reduce  weapon-sy^em  acquisition  time,  support  costs,  and 
improve  both  data  and  product  quality.  Given  the  current  state  of  the  DoO  budget  and 
the  likelihood  that  DoD  dollars  will  continue  to  shrink  in  the  foreseeable  future,  it  is  even 
more  imperative  that  Acquisition  Managers  maximize  the  use  of  CALS  as  a  springboard 
to  reduced  acquisition  and  downstream  O&S  costs. 

The  efficient  utilization  of  the  LSA  process  during  a  system's  early  life  cycle  (design  and 
early  developmerrt)  is  the  cornerstone  to  reducing  the  overall  system  O&S  costs.  But  in 
addition  to  simply  applying  the  LSA  process  during  a  design  phase,  the  Acquisition 
Managers  must  implement  an  effective  and  logical  approach  to  the  overall  acquisition 
and  management  of  fjll  data  irtciuding  data  associated  with  LSA,  ILS,  and  engineering 
and  program  management  through  the  entire  life  cycle  of  a  system.  It  is  no  longer 
acceptable  to  procure  and  reproduce  data  when,  in  fact,  the  only  difference  is  the 
format  Significant  cost  savings  can  be  realized  by  both  buying  and  utilizing  previously 
procured  data  in  a  logical  and  controlled  manner.  The  implementation  of  a  CALS 
strategy  will  allow  the  Acquisition  Manager  to  provide  the  foundation  to  electronicaily 
share  the  data  that  is  developed  from  his/her  program  with  multiple  users,  muttiple 
times.  Future  CALS-related  modernization  efforts,  including  those  presently  underway, 
will  help  improve  and  consolidate  both  data  acquisition  and  data  management.  But, 
until  these  efforts  are  completed,  It  is  the  individual  Acquisition  Manager's  responsibility 
to  apply  CALS  to  the  maximum  benefit  of  both  his/her  program  and  the  Naval  Forces  in 
general. 
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ABSTRACT 


This  document  presents  a  brief  overview  of  the  initial  CALS  standards  including  their 
purpose,  current  status,  and  implementation  issues.  It  concentrates  on  the  CALS 
spedftcations  implemented  by  MIL-STD-1840,  >^omated  interchange  of  Technical 
Informatioa 


ADMINISTRATIVE  INFORMATION 


This  report  was  developed  at  the  Carderock  Division,  Naval  Surface  Warfare  Center 
(formerly  David  Taylor  Research  Center)  under  Navy  CALS  funding  for  CALS 
Standards  Technical  Support  sponsored  by  the  Navy  CALS  Coordination  Office,  Naval 
Supply  System  Command  (NAVSUP  06). 


1.0  INTRODUCTION 


Tho  OoD  and  Industry  Computer-aided  Acquisition  and  Lo^stic  Support  (CALS) 
initiative  is  an  effort  to  accelerate  the  use  and  integration  of  digital  technioy  information 
in  the  weapon  system  acquisition  and  life  cycle  support  process.  CALS  is 
spearheading  a  transition  from  a  paper-intertsive  mode  of  operatimi  to  a  digital 
information  environment  aimed  at  improving  the  efficiency  of  ^ese  processes  and 
quality  of  the  products.  Many  organizations  create  arKl  m^ntain  data  in  digital 
electronic  form.  This  data  represents  computer-based  models,  desi^,  drawings, 
engineering  data,  technical  documentation,  arid  manufacturing  data. 

The  Department  of  Defense  (DoO)  CALS  Evaluation  and  Integration  Office  is  adt^ng 
and  developing  data  and  information  standards  and  specifications  to  provide  the 
common  Interfaces  and  neutral  file  formats  necessary  for  ^e  effective  interchange  and 
efficient  use  of  digital  technical  data.  CALS  policy  is  to  use  existing  and  emerging 
national  and  international  standards  wherever  possible  to  achieve  this  ot^ective. 
Initially,  CALS  is  focusing  on  standards  for  the  electronic  interchange  of  digital  technical 
inform^on  among  dissimilar  computer  systems.  These  initiai  CALS  standards  are 
intended  to  enable  the  digital  delivery  of  engirreering  drawings,  illustrations,  technical 
manuals,  and  engineering  data  Future  standards  wOl  focus  on  complete  product 
definition  data,  product  models,  and  the  need  to  access  and  manage  data  within 
distributed  database  environments. 

This  document  updates  the  "CALS  Standards  Ovenriew*  published  in  May  1992  as 
Section  9  of  the  first  edition  of  the  ‘Navy/Marine  Corps  Manager's  Desktop  Guide  for 
CALS  Implementation*.  It  updates  and  re\nses  the  CALS  Standards  information  to  be 
current  with  the  status  of  these  standards  in  June  1993.  The  overview  briefly 
summarizes  each  of  the  current  CALS  standards  and  addresses  their  purpose,  current 
status,  and  implementation  issues,  it  concentrates  on  the  CALS  specifications 
implemerned  by  MIL-STD-1840,  Automated  interchange  of  Technical  Information, 
notably: 

1 .  MIL-STD-1 840,  Automated  interchange  of  Technical  Information 

?  MIL-D-2800n,  Digital  Representation  for  Communication  of  Product 

Dat:^  .^plication  Subsets 

3.  MIL-M-28001,  Markup  Requirements  and  Generic  Style  Spedflcation  for 
Electronic  Printed  Output  and  Exchange  of  Text 

4.  MIL-R-28002,  Requirements  for  Raster  Graphics  Representation  in 
Binary  Format 
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5.  MIL-D-28003,  Digital  Representation  for  Communication  of  Illustration 
Data;  CGM  Application  Profile 

6.  The  Interactive  Electronic  Technical  Manual  Specifications,  MIL-M* 
87268,  MIL-D-87269,  and  MIL-Q-87270. 

Summary  information  is  also  provided  for  Electronic  Data  Interchange  Format  (EDIF), 
VHSIC  Hardware  Description  Language  (VHOi4,  and  Hypermedia  Time-based 
Document  Structuring  Language  (HyTime)  as  they  are  referenced  by  MIL'STD-i840. 
The  Open  Document  Architecture  (ODA)  standard,  though  not  a  CALS  standard,  is  also 
discussed  because  of  its  connection  with  the  CALS  raster  specification  MIL-R-28002. 
Finally,  a  section  has  been  devoted  to  STEP  (Standard  for  the  Exchange  of  Product 
Model  Data).  Though  not  now  an  official  CALS  standard,  the  DoD  will  adopt  STEP  for 
future  CALS  product  model  data 
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SECTION  2  -  AUTOMATED  INTERCHANGE  OF  TECHNICAL  INFORMATION 
MIL.STD-1840B 

2.1  PURPOSE 

MIL-STD-1840B  serves  as  a  central  standard  for  the  CALS  (Computer-aided 
Acquisition  and  Logistic  Support)  environment  It  supersedes  aruf  enhances 
MIL-STD-1840A  and  standardizes  formats  for  the  exchange  of  digital  information 
between  organizations  or  systems  in  order  to  facOKale  the  development  and  logistic 
support  of  defense  systems  throughout  their  entire  life  cycle. 

MIL-STD-1840B  defines  the  format  of  the  data  to  be  exchanged  in  the  CALS 
environment  as  well  as  the  mechanisms  and  the  parameters  of  those  mechanisrm, 
required  for  the  exchange  to  take  place.  Additionally,  MIL-STD-1840B  addresses 
electronic  product  data,  new  packaging  of  data  for  electronic  trade  business 
transactions,  and  electronic  product  data  technology. 

The  MIL-STD-1840B  standard  defines,  by  reference,  the  formats  and  structures  of  the 
data  files  used  for  the  transfer  and  archival  of  technical  data  in  digital  form.  It  clearly 
defines  the  formats,  standardized  header  records,  contents  of  the  files  used  for  the 
exchange  of  data  as  well  as  requirements  during  shipment  for  the  labeling,  protection, 
packaging,  and  the  marking  of  media  The  provisions  for  "protection*  of  media  require 
that  eiectromagnetically  inscribed  information  transfer  media  such  as  encoded 
magnetic  tapes  and  disks  be  protected  against  dirt,  moisture,  and  electrostatic 
discharge  damage  during  shipment 

2.2  TYPICAL  APPUCATIONS 

The  MIL-STD-1840B  standard  is  designed  to  be  usable  for  ail  CALS-related 
applications  where  the  information  can  be  prepared  and  received  as  ASCII  (American 
Standard  Code  for  Information  Interchange)  text  files,  product  definition  data  files, 
raster  image  files,  graphics  files,  or  contract  defined  data  files.  This  standard  is  not 
designed  to  be  usable  for  specific  applications,  but  is  not  restricted  in  any  way  in  its 
application. 

This  military  standard  is  irrtended  for  technical  Information  which  includes  product  data, 
product  acquisition  and  implementation  data,  and  product  support  data.  Product  data 
includes  engineering  drawings,  specifications,  as  well  as  new  and  evolving  digital  data 
forms  which  provide  the  data  In  a  platform  independent  form  directly  usable  by 
computer  applications.  Product  acquisition  and  implementation  data  includes 
parameters  and  data  necessary  to  manufacture  and/or  acquire  an  entire  defense 
system.  Product  support  information  includes  training  and  maintenance  manuals  with 
their  associated  illustrations  needed  to  maintain  a  defense  system  in  a  required  state  of 
readiness.  The  scope  of  this  data  covers  the  entire  life  cycle  of  a  weapon  system. 
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MIL-STD-1840B  provides  general  requirements  for  Technical  Publication,  Product 
Data,  and  Electrical/Eiectronic  Application  Data  RIe  document  types.  The  Technical 
Publications  document  type  includes  files  that  contain  MIL*M*28001  SGML  (Starxlard 
Generalized  Markup  Language),  Document  Type  Declaration  v/ith  no  text,  FOSI 
(Formatting  Output  Specification  Instance),  SGML  text  entity.  MIL*D*2B000  IGES  (Initial 
Graphics  Exchange  Specification),  MIL*R*26002  Raster,  MIL-0-28003  CGM  (Computer 
Graphics  Metafile),  PDL  (Page  Description  Language),  grey  scale  or  color  illustration,  or 
special  word  data. 

The  Product  Data  document  type  includes  files  that  represent  engineering  drawings  in 
IGES  or  raster  formats  as  well  as  Numerical  control  manufacturing  and  3-dimensional 
piping  data  files. 

The  Electrical/Bectronic  Application  Data  RIes  document  type  includes  files  that 
contain  information  in  the  following  formats:  Electronic  Design  Interchange  Format 
(EDIF).  the  Very  High  Speed  Integrated  Cinxrit  (VHSIC)  Hardware  Description 
Language  (VHDl^.  IGES  Electrical/Bectronic  appHcation  data  files,  and  Institute  for 
Interconnecting  and  Packaging  Electronic  Circuits  (IPC). 

In  any  typical  application,  the  hardware  and  software  must  prepare  the  files  for  transfer 
on  the  sending  system  by  adding  header  irtformation  and  writing  the  files  to  the 
selected  media  type.  The  hardware  and  software  on  the  receiving  system  must 
process  the  files  by  reading  the  files  from  the  selected  media  type  and  stripping  the 
added  header  information.  The  media  must  also  be  labeled,  protected,  packaged,  and 
marked  appropriately  during  shipment  in  accordarx;e  with  this  standard. 

2.3  ARCHITECTURE 

MIL-STD-1840B  is  composed  of  the  following  six  sections: 

Section  1  -  SCOPE:  Defines  the  scope  of  MIL-STD-1840B  with  respect  to 
standardizing  the  exchange  of  digital  information  between  organizations  or  systems. 

Section  2  -  REFERENCED  DOCUMENTS:  Identifies  all  of  the  documents  upon 
which  MIL-STD-1840B  is  based  (See  Section  2.9  of  this  overview). 

Section  3  -  DEFINITIONS:  Defirtes  the  abbreviations  and  terms  used  in 
MIL-STD-1840B. 

Section  4  -  GENERAL  REQUIREMENTS:  Specifies  the  general  requirements  of 
mandatory  declaration  files  as  well  as  the  specific  standards,  specifications,  and 
formats  required  for  data  files  covered  by  this  standard  (See  section  2.2  of  this 
overview^. 

Section  5  -  DETAILED  REQUIREMENTS:  Specifies  the  structure,  contents, 
media  options,  and  the  packaging  requirements  of  the  digital  irtformation  constituting  a 
transfer  package.  It  lists  file  naming  conventions  for  both  declaration  and  data  files 
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along  with  the  header  records  these  files  require.  The  information  required  in  these 
records  includes  identifiers  of  the  parent  file,  text  files,  data  files,  as  well  as  destination 
and  source  system  document  identifiers.  Packaging  requirements  specified  by 
MIL-STD<1840B  include  detailed  instructions  for  labeling,  protecting,  marking,  and 
packaging  the  transfer  media  for 
shipment 

Section  6  -  NOTES:  Provides  information  which  is  helpful,  but  not  mandatory. 

2.4  STATUS  AND  PLANNED  EXTENSIONS 

MIL-STD-1840B  was  released  on  November  3,  1992.  It  supersedes  MIL-STD-1B40A 
which  was  released  5  years  earlier  on  December  22,  1987.  The  next  version  of  this 
standard  is  expected  in  late  1995. 

MiL*STD-1840B  is  required  for  the  delivery  of  technical  CALS  data.  It^  approved  for 
use  by  all  agencies  of  the  Department  of  Defense  (DoD).  It  has  been  implemented  and 
used  successfully  by  numerous  vendors.  The  use  of  MIL>STD-1840B  v^li  undoubtedly 
continue  to  grow  since  this  standard  is  at  the  heart  of  the  CALS  interchange 
environment  The  Department  of  Defense  will  continue  to  require  that  CALS 
procurements  adhere  to  the  requirements  of  this  starxlard. 

The  future  Revisions  of  MIL-STD-1840B  will  address  solid  modeling  for  system  design, 
interactive  retrieval  and  use  of  technical  information,  and  other  poterrtial  computer 
applications  for  defense  systems  of  the  future.  The  interactive  retrieval  and  use  of 
information  will  be  necessary  for  the  implementation  of  the  Contractors  Integrated 
Technical  Information  Senrice  (CITIS)  and  the  Integrated  Weapon  System  Data  Base 
(IWSDB).  It  is  expected  that  expert  systems  will  be  included  in  future  revisions. 

MiL-STD-1840  continues  to  recognize  the  format  required  for  IGES  information,  but 
does  not  attempt  to  address  STEP  (Standard  for  the  ^change  of  Product  data  model) 
or  PDES  (Product  Data  Exchange  standard  using  STEP)  formats.  This  wiU  be  done  in 
future  revisions  of  MIL-STD-1840. 

Many  of  the  standards  and  specifications  required  or  referenced  by  MiL-STD-1840B 
are  evolving  significantly  due  to  rapidly  advancing  technologies.  These  will  have  to  be 
further  implemented  in  ^ure  revisions  of  this  standard. 

Efforts  are  currently  under  way  to  form  a  recognized  working  group  vrith  international 
participation.  A  target  capability  (tcap)  document  is  being  developed  for  circulation 
among  the  CALS  Industry  Steering  Group  (ISG).  It  recommends  that  the  following 
areas  be  addressed  in  the  next  revision  of  MIL-STD-1840B: 

•  Emerging  technologies  such  as  object  oriented  design,  multi-media 
Interactive  Electronic  Technical  Manuals  (lETMs),  Electronic  Data 
Interchange  (EDI),  Electronic  Commerce  (EC),  and  ISO  STEP. 
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•  Make  MIL-STO-1 640B  media  independent. 

•  Develop  a  capability  for  exchange  of  data  bases  and  data  dictionaries  via 
Information  Resources  Dictionary  System  (IRDS). 

•  Handle  lETMs,  multi-media,  and  hot  links. 

•  Allign  to  ISO  10303  (STEP). 

•  Allign  to  EDI  for  Administration,  Commerce,  and  Transport  (EDIFACT). 

•  Handle  SGML  Document  Interchange  Format  (SDIF). 

•  Restructure  for  Telecommunication  Standards  such  as  x.400.  x.435.  x.500 
etc. 

•  Provide  improved  indexing  to  systems  governed  by  standard  data  dictionary. 

•  Provide  for  improved  security  handling  consistent  with  the  OSi 
telecommunications  model. 

•  Provide  for  better  methods  for  compression  and  encryptioa 

•  Provide  a  mechanism  for  exchange  of  software  and  training  miti»^riais 
including  interactive  courseware  and  simulation  training  materials. 

•  Develop  and  standardize  an  approach  to  provide  automated  technical 
information  (ATI)  targeted  to  interactive  storage  and  retrieval  by  an  end  user 
via  technical  data  repository. 

•  Provide  a  "grandfather*  clause  to  accommodate  systems  and  interchanges 
initiated  prior  to  the  current  1840  version. 

2.5  ADVANTAGES  OF  CURRENT  STANDARD 

MIL-STD-1840B,  a  standard  for  interchanging  digital  technical  data,  is  a  core  standard 
for  the  CALS  environmert.  iii  addition  to  the  advantage  of  being  required  for  the 
delivery  of  CAL''  nis  standard  has  the  advantage  of  having  an  essential  function 
which  facilitates  me  sharing  of  technical  data  within  and  among  autonomous 
organizations. 

This  standard  clearly  defines  the  mechanisms  for  exchanging  digital  data  with  formats 
defined  in  other  CALS  specifications  (MIL-D-28000.  MIL-M-28001,  MIL-R-28002,  and 
MIL-D-28003).  The  reference  to  and  use  of  other  standards  and  specifications  allows 
this  standard  to  evolve,  as  those  standards  and  specifications  evolve,  in  order  to  take 
advantage  of  advances  in  current  technologies  or  to  use  new  technologies. 
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MIL-STD-1840B  contains  specific  detailed  instaictions  for  usirtg  9-track  magnetic  tapes 
as  a  medium  for  exchange  of  digital  data.  It  contains  flexible  provisions  which  rely  on 
agreements  between  sender  and  receiver  for  using  other  media  such  as  diskettes, 
WORM  (Write  Once  Read  many-times)  optical  disks,  and  CD-ROM  (Compact  Disk 
Read  Only  Memory)  for  the  exchange  of  technical  data.  This  reliance  on  agreements 
provides  MIL-STD-1840B  with  the  advantage  of  being  accommodating  to  changing 
user  needs  as  well  as  being  able  to  adapt  to  new  requirements  and/or  guidelirtes. 

Another  advantage  of  MIL-STD-1840B  is  that  it  cieariy  defines  the 
formats,  standardized  header  records,  and  the  contents  of  the  files  used  for  the 
exchange  of  data  as  well  as  requirements  for  the  labeling,  protection,  packaging,  and 
the  marking  of  media  during  shipment  The  standard  also  addresses  electronic  product 
data,  new  packaging  of  data  for  electronic  trade  business  transactions,  and  electronic 
product  data  technology. 


2.6  IMPLEMENTATION  ISSUES 

MiL-STD-1840B  is  required  for  the  delivery  of  CALS  technical  data.  However,  the 
media  for  delivery  must  still  be  selected.  This  standard  specifies  the  media  for 
exchange  of  CALS  information  and  includes  provisions  for  using  nine-track  magnetic 
tapes,  diskettes,  WORM  optical  disks,  and  CD-ROM. 

Although  given  recognition  as  viable  CALS  media  actual  specifications  for  CD-ROM 
and  WORM  optical  disks  are  not  cieariy  defined  in  this  standard.  The  generic 
description  of  requirements  leaves  room  for  portability  problems  in  the  areas  of 
placement,  arrangement,  and  structuring  of  files  on  media  other  than  9-track  magnetic 
tapes.  Informal  agreements  between  sender  and  receiver  must  be  made  to  ensure 
complete  portability  when  CALS  data  is  interchanged  on  any  medium  other  than  9-track 
tapes.  In  addition,  other  media  such  as  the  Bernoulli  removable  disk  drives  are  not 
considered,  thereby  leaving  the  impression  they  are  not  to  be  used. 

Corresponding  hardware  and  software  must  be  present  at  the  preparing  (source, 
sending)  site  and  the  receiving  (destination)  site  to  accommodate  the  selected  media 
for  the  information  interchange.  The  files  on  the  sending  system  must  be  prepared  for 
transfer  by  adding  header  information  to  them  and  writing  them  to  the  selected  media 
type.  The  files  must  be  processed  on  the  receiving  system  by  reading  them  from  the 
selected  merfia  type  and  stripping  the  added  header  information.  The  configuration 
management  functionality  of  MIL-STD-1640B  requires  careful  management  within  the 
software  to  assure  that  correct  information  is  added  to  the  file  headers. 

MIL-STD-1840B  does  not  handle  the  frequently  encountered  problem  of  multi-volume 
files,  if  a  file  is  spread  across  several  volumes  (tapes),  there  are  many  different  ways 
that  the  information  could  be  recovered.  This  is  a  problem  with  implementation  that  has 
been  raised,  but  rK)t  adequately  handled  in  the  standard. 
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The  "encouragemenf  that  the  data  communications  protocol  specifications  of  QOSIP 
(Government  Open  Systems  Interconnection  Profile)  be  used  with  this  standard  raises 
the  possibility  of  the  need  to  implement  additional  requirements.  This  results  from  the 
fact  that  GOSIP  references  other  standards  such  as  OOA  (Open  Desk  Architecture). 
The  perceived  possibility  of  additional  overhead  and  requirements  resulting  from  the 
referertce  to  GOSIP  would  be  resolved  if  all  standards  required  or  referenced  by  the 
data  communication  protocol  specifications  of  GOSIP  were  dearly  identified. 

When  this  standard  is  referenced  by  contract,  it  only  applies  to  contract  data  called  out 
in  the  Contract  Data  Requirements  List  (CDRL).  Each  item  in  the  CDRL  must  be 
annotated  on  the  respective  DO  Form  1423  indicating  that  MIL-STD<1840  specifies  the 
format  for  delivery.  The  content  of  the  information  to  be  delivered  is  defined  by  the 
Data  Item  Descrif^on  (DID)  referenced  by  the  CDRL 


2.7  E}CrENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

MIL-STD-1840B  is  approved  for  use  by  all  agencies  of  the  Department  of  Defense.  It 
is  required  for  the  delivery  of  all  CALS  data.  This  military  standard  specifies  other 
standards  which  are  widely  supported  and  accepted  by  national  as  well  as  international 
standards  organizations.  This  provides  a  strong  foundation  for  user  and  vendor 
support 

The  real  extent  of  the  use  of  MIL-STD-1840B  depends  upon  the  use  of  the  standards 
of  interchange  which  it  specifies.  Additional  information  can  be  obtained  about  users 
and  vendors  who  are  implementing  MIL-STD>1840B  as  a  part  of  their  Implementation  of 
these  CALS  standards  and  specifications  by  reviewing  this  same  section  of  the 
summaries  for  MIL-M-28001  SGML,  MIL-D-28000  IGES,  MiL-R-28002  Raster,  or 
MIL-D-28003  CGM. 

The  CALS  Test  Network  (CTN)  was  established  to  perform  end-to-end  testing  of  the 
exchange  of  digital  data  using  MIL-STD-1840B.  *CALS-compiianf  systems  must  have 
the  capability  of  reading  and  generating  data  or  media  conforming  to  MIL-STD-1840B. 
Since  MIL-STD-1840B  is  at  the  heart  of  the  CALS  interchange  environment,  DoD  will 
continue  to  require  that  CALS  procurements  adhere  to  the  requirements  of  this 
standard. 


2.8  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

MIL-STD-1840B  was  developed  by  the  National  Institute  of  Standards  and  Technology 
(NIST)  under  the  direction  of  the  Office  of  the  Secretary  of  Defense  (OSD)  CALS  Office. 
All  of  the  CALS  standards  including  MIL-STD-1840B  are  currently  being  managed  by 
the  CALS  Digital  Standards  Office  (CDSO),  at  Wright  Patterson  Air  Force  Base, 
Dayton,  Ohio. 
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2.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 


SPECIFICATIONS 


FEDERAL 

PPP-B-636 

PPP-C-1842 

MILITARY 

MIL-D-28000 


MIL-M-28001 


MIL-R-28002 


MIL-0-28003 

STANDARDS 

MIL-STD-1840B 


Boxes.  Shipping.  Rberboard. 

CusNoning  Materiel.  Plastic.  Open  Cel  (for 
Packaging  Purpose). 

Digital  Representation  for  Communication  of 
Product  Data*  IGES  Application  Subsets  and  IGES 
Application  Protocols. 

Markup  Requirements  and  Generic  Style 
Specification  for  Electronic  Printed  Output  and 
Exchange  of  Text 

Requirements  for  Raster  Graphics 
Representations  in  Binary  Format 

Digital  Representation  for  Communication  of 
illustration  Data:  CGM  Application  Profile. 

Automated  interchange  of  Technical 
information 


MIL-STD-804  -  Formats  and  Coding  of  Aperture  Cards. 


MIL-STD-1806 

HANDBOOKS 

MIL-HDBK-59 


Marking  Technical  Data  Prepared  by  or  for  the 
Department  of  Defense. 

Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  Program 
Implementation  Guide. 


MIL-HDBK-331  •  Directory  of  DoD  Engineering  Data  Repositories 

Copies  of  federal  and  military  specifications,  standards,  and  handbooks  are  available 
from  the  StarKiardization  Document  Order  Desk.  Building  4D.  700  Robbins  Ave. 
Philadelphia,  PA  19111-5094.) 


INTERNATIONAL  ORGANIZATION  FOR  STANDARDIZATION  (ISO) 

ISO  8879-1986  -  information  processing  -  Text  and  Office  Systems 

Standard  Generalized  Markup  Language  (SGML). 
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(Copies  are  available  from  the  American  National  Standards  Institute.  1 1  West  42nd 
Street.  13  Root,  New  York.  NY  10036.) 

AMERICAN  NATIONAL  STANDARDS  INSTITUTE  (ANSI) 


ANSI  X3.4-1986 

ANSI  X3.27-1987 

ANSI  X3.39-1986 

ANSI  X3.54>1986 


American  National  Standard  Code  for  Information 
interchange. 

RIe  Structure  arul  Labeling  of  Magnetic  Tapes  for 
Information  Interchange. 

Recorded  Magnetic  Tape  for  Information 

Interchange  (1600  CPI.  P.G.). 

Recorded  Magnetic  Tape  for  Information 

Interchange  (6250  CPI.  Group  coded  Recording). 


(Application  for  copies  should  be  addressed  to  American  NatioruU  Standards  Institute, 
1 1  West  42nd  StreeL  13  Roor,  New  York.  NY  10036.) 


ELECTRONIC  INDUSTRIES  ASSOCIATION  (BA) 


EIA  548  •  Electronic  Design  Interchange  Format  (EDIF). 

EIA  5670000  Commercial  Component  Model  Specification. 

(Application  for  copies  should  be  addressed  to  the  Bectronic  industries  Association, 
2001  Pennsylvania  Ave.  North  West,  Washington,  DC  20006.) 


INSTITUTE  FOR  INTERCONNECTING  AND  PACKAGING  ELECTRONIC  CIRCUITS 
(IPC) 

iPC-D-350  •  Printed  Board  Description  in  Distal  Form. 

IPC-D-351  •  Printed  Board  Drawings  in  Digital  Form. 

IPC-D-352  •  Electronic  Design  Data  Description  for  Printed 

Boards  in  Digital  Form. 

iPC-D>354  •  Library  Format  Description  for  Printed  Board  Digital 

Form. 

iPC-D-356  •  Bare  Board  Electrical  Test  Information  in  Digital 

Format 


(Application  for  copies  should  be  addressed  to  the  Institute  for  Interconnecting  and 
Packaging  Electronic  Circuits,  7380  N.  Lincoln  Ave.,  Lincolnwood,  IL  60646.) 
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INSTITUTE  OF  ELECTRICAL  AND  ELECTRONICS  ENGINEERS  (IEEE) 

IEEE  1076  -  VHSiC  Hardware  Description  Language  (VHDL). 

(Application  for  copies  should  be  addressed  to  The  Institute  of  Electrical  and 
Bectronics  Engineers,  Inc.,  345  E.  47^  Street,  New  York,  NY  10017.) 
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SECTION  3  ■  DIGITAL  REPRESENTATION  FOB  COMMUNICATION  OF 
PRODUCT  DATA:  IGES  APPLICATION  SUBSETS  AND  IGES  APPUCATION 
PROTOCOLS  (MIL-P.280QQAI 

3.1  PURPOSE 

MIL-D-28000A  is  the  military  specification  for  the  digital  representation  of 
product  definition  data  using  the  Initial  Graphics  Exchange  Specification  (IGES) 
as  spedfied  by  the  American  Sodety  of  Medianical  Engineers  (ASME)  standard 
Y14.26M  (Digital  Representation  for  Communication  of  Product  Definition  Data). 
MIL-D-28000A  is  organized  into  five  dasses  by  application  area  to  meet  the 
delivery  needs  of  that  application. 


1 

Technical  Illustrations  Subset 

II 

Engineering  Drawings  Subset 

III 

Electrical/Bectronic  Applications  Subset 

IV 

Geometry  for  NC  Manufacturing  Subset 

V 

3D  Piping  Application  Protocol 

The  basic  unit  of  information  within  a  MiL-D>28000A  dass  is  an  entity,  such  as 
a  line,  point,  cirde,  conic  arc.  The  subsets  are  composed  of  entities  from  ASME 
Y14.26M  -  1989,  the  equivalent  of  IGES  Version  4.0.  The  Application  Protocol 
(dass  V)  is  composed  of  entities  from  IGES  Version  5.1.  A  MIL-D'28000A  file 
must  use  one  of  the  five  approved  dasses,  indicating  the  specific  class  used 
in  the  start  section  at  the  beginning  of  the  MIL-D-28000A  file. 

MIL-D-28000A  is  maintained  by  the  Office  of  the  Assistant  Secretary  of  Defense 
(OASD).  It  is  managed  for  OASD  by  tfie  CALS  Digital  Standards  Office  (CDSO) 
in  Dayton  Ohio.  Carderock  Division,  NSWC  is  the  technical  agent  for  MIL-D- 
28000A.  Following  is  a  list  of  the  different  versions  of  MIL-D-28000: 
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MIL-D-28000 

December 

1987 

Initial  Version  -  Classes  1,  II  &  III.  Uses 
ANSI/ASME  Y14.26M  - 1987  &  IGES 

4.0. 

MIL-D-28000 
Amendment  1 

December 

1988 

Added  class  IV. 

MIL-D-28000A 

February 

1992 

Uses  ASME  Y14.26M  -  1989  &  IGES 

5.1.  Added  dass  V. 

M1L-D-28000A 
Amendment  1 

December 

1992 

Added  missing  entities. 

3.2  SCOPE 

MIL-D-28000A  specifies  five  classes  of  the  IGES  standard  (technical 
illustrations,  engineering  drawings,  electronic/electronics  applications, 
numerical  control  manufacturing,  and  3D  piping)  as  opposed  to  the  entire  IGES 
standard.  MIL-D-28000A  subdivides  the  IGES  specification  because  IGES  is 
large  and  complex,  with  different  options  that  may  be  used  to  represent  the 
same  Computer  Aided  Design  (CAD)  model  entity.  As  a  result,  CAD  software 
vendors  seldom  support  every  IGES  entity  in  the  specification,  but  support  a 
subset  of  IGES  that  best  matches  the  features  of  their  CAD  system.  Invariably, 
there  is  a  mismatch  between  the  set  of  entities  by  one  CAD  system's  pre¬ 
processor  and  another  CAD  system's  post-processor.  There  is  no  guarantee 
that  the  intersection  of  the  two  different  CAD  systems'  supported  IGES  entities 
is  adequate  for  the  required  data  transfer. 

3.2.1  APPUCATION  SUBSETS 

The  first  four  classes  of  MIL-D-28000A  specify  the  entities  needed  for  specific 
application  subsets.  In  this  way  the  recipient  of  a  MIL-D-28000A  data  file  may 
specify  the  class  of  data  needed  without  becoming  an  expert  on  the  IGES.  The 
only  other  entities  allowed  in  the  file  are  •volunteer*  entities.  As  stated  by  MIL-D- 
28000A.  “volunteer"  entities  must  be; 

•  Valid  ASME  Y14.26M  entities, 

•  Not  necessary  for  the  product  data  representation,  and 

•  Meant  only  for  restoring  the  environment  on  the  CAD  system  that 
originally  developed  the  file  for  transmittal. 
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These  requirements  are  placed  on  volunteer  entities  so  that  the  CAO  system 
that  receives  the  file  will  not  lose  product  information  if  it  does  not  transfer  the 
Volunteer^  entities. 

The  MIL-D>28000A  application  subsets  specify  the  entities  allowed  in  that 
class  through  a  list  of  ASME  Y14.26M  entities  given  in  table  form.  Limits  on  the 
entities  are  given  through  notes  on  that  table.  Rules  are  also  given  for  the  entity 
construction.  Guidance  is  provided  for  M1L-D-28000A  file  construction 
requirements  for  each  section  (start  section,  global  section,  directory  entry 
section,  parameter  data  section,  and  terminate  section)  of  an  IGES  file  for 
each  class. 

The  subset  concept  addresses  many  of  the  user's  problems,  but  is  not  an 
entire  solution.  One  difficulty  is  that  the  subsets  address  the  needs  of 
applications  by  directly  specifying  the  particular  IGES  entities  to  be  included  in 
the  subsets,  but  do  not  include  enough  information  on  how  to  use  those 
entities  to  transfer  all  the  product  data  typically  needed  by  that  application.  Most 
IGES  entities  are  general  purpose  in  nature.  They  can  be  combined  to  create 
constructs  needed  for  product  data  transfer,  such  as  a  circuit  in  an  electrical 
application,  but  they  do  not  rigorously  define  how  this  is  done.  This  can  be  a 
problem  in  transfer,  because  unless  the  receiving  system  knows  how  the  IGES 
entities  were  combined  to  create  the  construct,  and  has  a  rigorous  definition  of 
the  meaning  of  the  construct,  that  receiving  system  will  not  be  able  to  interpret 
the  construct  The  basic  data  is  translated,  but  not  all  the  information  needed  to 
translate  product  data  for  the  application  is  transferred. 

The  four  application  subsets  defined  witi^in  MIL-D-28000A  are  described  in  the 
following  paragraphs. 

Class  I:  Technical  Illustrations  Application  Subset.  The  Class  I  application 
subset  is  for  the  exchcuige  of  illustrations  for  technical  publications.  The 
emphasis  is  on  the  visual  appearance  of  the  illustrations,  not  on  the  functionality 
of  the  entities  within  the  class.  Class  I  is  a  two  dimensional  subset  with  limited 
non-geometric  information  (such  as  subfigures). 

Class  II:  Enaineerino  Drawings  Application  Subset  The  Class  II  application 
subset  is  for  the  exchange  of  product  data  following  MiL-T-31000  (Technical 
Data  Packages,  General  Specification  for).  The  emphasis  is  on  completeness, 
functionality  of  the  drawing  model,  and  visual  equivalency  for  human 
interpretation.  The  class  contains  many  geometric  entities,  annotation  entities 
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and  attributes  such  as  color  and  line  fonts,  along  with  organizational  information 
such  as  levels  and  subfigures.  The  geometric  entities  in  this  dass  are  three 
dimensional,  though  two  dimensional  data  can  be  transferred  by  pladng  all  the 
information  on  the  same  plane  within  the  sending  CAO  system. 

Class  III:  Electrical/Electronic  Applications  Subset  The  Class  III  application 
subset  is  for  the  exchange  of  product  data  for  electrical  and  electronic  p)roducts. 
The  emphasis  is  on  completeness  and  functionality  of  the  model  for  design, 
manufacturing  and  testing.  Class  III  supports  both  tfie  logical  product 
representation  and  the  physical  product  representation,  which  can  both  be  in 
the  same  file.  The  logical  representation  indudes  netlists  and  schematics, 
while  the  physical  representation  indudes  assembly  placement  and  pad  layouts. 

Class  IV:  Geometry  for  NC  Manufacturing  At)plication  Subset  The  Class  IV 
application  subset  is  for  the  exchange  of  product  data  for  manufacturing  by 
numerical  control.  The  emphasis  is  on  the  completeness  and  functionality  of 
the  part  model.  Geometry  data  is  either  2-D  wireframe,  for  profiles  or  sheet 
metal,  or  a  3-D  wireframe  model,  for  multi-axis  machining.  Predsion  and 
accuracy  on  the  wireframe  and  surface  geometry  must  be  maintained,  as  well 
as  first  order  continuity.  Geometry  and  Text  form  the  majority  of  the  data  for  this 
class. 


3.2.2  APPUCATION  PROTOCOLS 

An  Application  Protocol  (AP)  is  a  way  to  transfer  defined  product  data  through 
IGES.  An  AP  documents  the  user  requirements  for  an  application  in  a  graphical 
model  called  an  Application  Reference  Model  (ARM).  The  requirements  in  the 
ARM  are  then  represented  by  specific  IGES  entities  in  a  given  AP  (the  AIM).  APs 
enable  IGES  to  be  used  to  transfer  product  data  reliably  until  PDES/STEP  is 
available  from  the  commercial  CAO  vendors.  APs  provide  a  defined  and  more 
reliable  method  for  transferring  product  data  through  IGES. 

An  AP  is  composed  of  the  following  elements: 

•  A  scope  and  requirements  section; 

•  An  Application  Reference  Model  (ARM)  of  the  supported  information 
that  explains  what  is  covered  in  the  application  and  how  the  different 
elements  relate  to  one  another. 
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•  An  Application  Interpreted  Model  (AIM)  that  shows  how  the  information 
is  mapped  into  IGES  entities;  and 

•  Conformance  Requirements  and  Abstract  Test  Purposes. 

APs  are  very  specific  in  nature.  For  example  the  3D  Piping  AP  (Class  V) 
exclusively  supports  the  exchange  of  product  data  for  3D  piping  system 
models.  It  does  not  support  piping  engineering  drawings.  A  user  wishing  to 
transfer  an  engineering  drawing  of  a  piping  system  would  have  to  use  an 
Engineering  Drawing  AP.  Also,  only  CAD/CAM  sy^ems  supporting  piping  will 
be  able  to  support  the  piping  AP.  A  CAD/CAM  system  that  does  not  support 
piping  just  doesnt  have  the  appropriate  constructs  within  its'  database  to 
either  output  data  in  tfie  Piping  AP.  or  input  the  data  reliably.  APs  will  provide 
increased  information  transfer,  but  with  a  much  narrowed  scope  in  the 
information  that  is  transferred. 

Class  V:  3D  Pioino  Application  Protocol.  The  Class  V  application  protocol  is  for 
the  exchange  of  product  data  for  3D  piping  system  models,  but  not  piping 
drawings  or  internal  details  of  equipment  The  Class  V  AP  conveys  shape  and 
location,  connectivity,  material  characteristics,  information  about  elements  in 
the  piping  system  and  the  piping  sy^em  as  a  whole.  The  Class  V  provides 
information  for  the  core  requirements  of:  interference  analysis,  connectivity 
checks,  basic  parts  lists,  graphics  presentation,  basic  piping  isometrics,  pipe 
bending  instructions,  and  limited  piping  redesign.  This  Class  V  AP  is  not 
intended  for  genera)  purpose  CAD  system,  but  for  3D  piping  system 
applications  only.  Both  the  sending  and  receiving  systems  must  support  the 
3D  piping  system  application  and  the  Class  V  3D  Piping  Application  Protocol 
for  meanin^l  exchange. 


3.3  STATUS  AND  PLANNED  EXTENSIONS 

MIL'D-28000A  is  based  upon  an  underlying  American  National  Standard 
(ASME  Y14.26M  -  1989)  and  the  Initial  Graphics  exchange  Specification  (IGES) 
Version  5.1,  both  of  which  were  develop^  by  the  IGES/PDES  Organuation 
(IPO).  As  such,  the  OASD  CALS  Evaluation  and  Intergration  Office  (ElO) 
cooperates  with  the  voluntary  IPO  through  the  IPO's  CALS/IGES  Special 
interest  Group  (SIG).  The  CALS/IGES  SIG  reviews  proposed  changes  and 
suggests  new  changes  at  the  IPO  meetings.  The  CALS/IGES  SIG  is  a  source 
of  IGES  technical  expertise  and  *s  instrumental  in  ensuring  the  quality  of 
revisions  or  amendments  to  MIL-D-28000A 


A  new  application  protocol,  the  Engineering  Drawings  Application  Protocol  (AP), 


is  being  developed  for  MIL-D-28000A.  It  is  being  created  by  members  of  the 
Navy  Industry  Digital  Data  Exchange  Standards  Committee  (NIDDESC)  and 
the  IGE^DES  Organization.  The  AP  will  be  submitted  to  the  OASD  CALS  ElO 
for  inclusion  in  the  next  amendment  or  revision  of  MIL>D-28000. 

Review  and  comments  generated  in  the  year  and  a  half  that  MIL-D-28000  has 
referenced  that  AP,  has  resulted  in  the  generation  the  3D  Piping  AP  version  1.2. 
The  3D  Piping  AP  version  1.2  is  under  a  mail  ballot  vote  of  the  IPO  general 
assembly.  After  the  AP  is  approved,  it  will  be  published  by  USPro  (the  parent 
organization  for  the  IPO)  as  a  companion  standard  to  the  IGES  specification 
and  submitted  to  the  OASD  CALS  ElO  for  inclusion  in  the  next  amendment  or 
revision  of  MIL-D-28000. 


3.4  IMPLEMENTATION  ISSUES 

The  metiiod  by  which  the  senders  of  a  MIL-D-28000A  file  will  produce 
application  subsets  is  a  possible  concern  for  the  implementation  of  MIL-D- 
28000A  The  preferred  method  is  for  the  originator's  CAD  system's  IGES 
translator  to  produce  the  MIL-D-28000A  file.  But  an  alternative  method  is  for 
the  CAD  system  to  produce  the  IGES  file  which  is  subsequently  run  through 
commercial  flavoring  software  to  produce  the  MIL-D-28000A  compliant  file. 

This  method  must  be  performed  very  carefully  to  prevent  any  loss  of  the  file's 
underlying  structure,  and  is  not  suited  for  the  transfer  of  application  protocols. 

Even  perfect  transfer  of  the  application  subset  does  not  ensure  that  all  of  the 
information  in  the  original  CAD  model  will  be  translated.  For  example,  a  CAD 
system  may  recognize  objects  such  as  resisters  and  capacitors  in  its  internal 
data  base,  but  since  IGES  has  no  standard  way  to  represent  such  objects, 
these  ot^ects  may  be  transferred  as  a  grouping  of  points,  lines  and  curves 
which  represent  the  object  The  concept  that  a  group  of  entities  represent  an 
object  is  not  necessarily  conveyed  by  the  subset  to  the  receiving  CAD  system. 
MIL-D-28000A  displays  an  awareness  of  this  problem  by  specifying  that  *lt  is 
the  intent  of  this  specification  to  evolve  in  the  direction  of  application  protocols 
to  ensure  quality  data  exchanges*.  The  application  protocol  work  is  being 
developed  within  the  IGES/PDES  Organization  to  transfer  objects  within  an 
application  area  instead  of  merely  a  geometric  representation  with  little 
standardized  intelligence  attached.  The  3D  Piping  AP  is  the  first  AP  developed 
by  the  IPO. 
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Most  IGES  entities  are  general  purpose  in  nature.  They  can  be  combined  to 
create  constructs  needed  for  product  data  transfer,  such  as  a  circuit  in  an 
eiectricai  application,  but  they  do  not  rigorously  define  how  this  is  done.  This 
can  be  a  problem  in  transfer,  because  unless  the  receiving  system  knows  how 
the  IGES  entities  were  combined  to  create  the  construct,  the  receiving  system 
may  not  be  able  to  interpret  it  The  basic  data  will  be  translated,  but  all  the 
information  needed  to  translate  product  data  for  the  application  will  not  be 
available. 

MIL-D-28CX)0  does  not  contain  any  rationale  for  why  a  specific  set  of  entities 
was  chosen  for  an  application  subset  over  another  set  of  entities.  This  can 
make  extensions  to  the  subsets  laborious,  and  raises  many  questions  from 
the  user  and  vendor  community. 


3.5  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

The  IGES  specification  has  much  support  from  CAO  system  vendors.  Most 
CAD  systems  have  some  type  of  IGES  translator,  and  even  some  non-CAO 
systems,  such  as  Interleaf  (an  electronic  publications  system),  support  the 
IGES  specification.  The  support  for  MlL-0-28000  0  ^.,  the  subsets)  is  not  as 
widespread  as  the  support  for  the  full  IGES  standard.  The  greatest  stated 
support  of  the  subsets  comes  from  the  commercial  flavoring  software  and 
syntax  checking  software.  MIL-D-28000  Class  11,  engineering  drawings,  is  the 
most  commonly  supported  class,  followed  by  MIL‘0-28000  Class  I,  technical 
illustrations.  Intergraph  has  a  MIL-0-28000  Class  V  translator  under 
development. 


3.6  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION(S) 

The  MIL-D-28000A  (IGES  subsets  and  APs)  specification  is  being  developed 
jointly  by  the  Department  of  Defense  (DoD),  federal  agencies  and  private 
industry,  under  the  direction  of  the  Department  of  Defense.  Comments  are 
solicited  through  the  postage  paid  Standardization  Document  Improvement 
Proposals  (DD  Form  1426)  at  the  back  of  the  MIL-D-28000A  specification.  The 
comments  that  are  accepted  are  incorporated  into  a  coordination  draft 
amendment  or  revision  to  the  standard.  This  coordination  draft  is  circulated  to 
Government  and  Industry  for  comment.  The  comments  are  reviewed  and 
incorporated,  then  a  new  version  of  the  specification  is  issued. 

The  CALS  Digital  Standards  Office  (CDSO)  in  Dayton  Ohio  is  the  administrative 
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agent  for  the  MIL-D-28000A  specification.  The  CDSO  is  responsible  for 
distributing  the  draft  specification  for  comment  receiving  and  tracking  the 
comments,  holding  the  comment  coordination  meetings,  updating  the  draft 
specification  with  the  comments,  and  supplying  the  completed  document  to 
OASD  for  approval. 

The  IGES/PDES  Organization  (IPO)  develops  and  maintains  the  standard  upon 
which  MIL-D-28000A  depends,  the  Initial  Graphics  Exchange  Specification 
(IGES).  The  IGES  project  is  guided  by  the  IGES  Project  Manager.  Mr.  Greg 
Morea  of  General  Oynamics/Eiectric  Boat  Changes  to  the  specification  are 
submitted  as  Request  For  Changes  (RFCs),  which  are  balloted  by  mail  to 
members  of  the  IPO  on  a  quarterly  basis.  An  RFC  is  approved  if  the  majority  of 
the  ballot  votes  are  favorable  and  all  untevorable  votes  are  classified  as  not 
persuasive  by  the  IPO  Technical  Committee  responsible  for  the  RFC.  An 
Engineering  Change  Order  (ECO)  is  then  prepared  for  the  approved  RFCs  by 
the  technical  committee  and  submitted  to  the  IGES  Editor  for  inclusion  into  the 
next  IGES  version. 

The  IPO  has  been  accredited  as  an  American  National  Standards  Institute 
(ANSI)  standards  making  body  for  product  data  exchange  in  1992.  IGES 
Version  5.2  will  become  the  first  national  standard  directly  created  by  the  IPO. 
Before  the  IPO  received  ANSI  accreditafion,  the  IPO  submitted  the  IGES 
specification  to  the  American  Society  of  Mechanical  Engineers  (ASME)  Y14.26 
committee  (Engineering  Drawing  and  Related  Documentation  Practices)  for 
approval,  and  for  publication  as  a  national  standard.  This  process  generally 
took  a  years  time,  which  lead  to  a  substantial  delay  between  publishing  of  the 
IPO  specification  and  publishing  the  national  standard. 

The  OASD  CALS  ElO  cooperates  with  the  voluntary  IPO  through  the  IPO's 
CALS/IGES  Special  Interest  Group  (SIG).  The  CALS/IGES  SIG  is  a  source  of 
IGES  technical  expertise  and  is  instrumental  in  ensuring  the  quality  of  revisions 
or  amendments  to  MIL-0-28CXX).  The  CALS/IGES  SIG  was  a  significant 
contributor  to  MIL-D-28000  Revision  A. 

The  CALS  Industry  Steering  Group  (ISG)  Standards  Task  Group  (STG)  Drawing 
and  Graphics  Committee  (DAGC)  also  participates  in  the  maintenance  of  MIL-D- 
28CXX)A.  The  OAGC's  interest  is  in  examining  and  evaluating  graphics  standards 
for  CALS  (such  as  MIL-R-28CX)2  (Raster).  MIL-D-28003  (CGM)  and  MIL-D- 
28000A  (IGES)  ).  Issues  developed  by  the  DAGC  are  documented  as  TCAPS 
(T echnical  CAPabilitieS).  TCAPS  that  are  approved  by  the  ISG  are  forwarded  to 
the  OASD  CALS  ElO  for  consideration.  The  DAGC  maintains  liaison 
relationships  with  the  other  graphics  organizations,  such  as  the  IPO,  to  keep 
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current  with  changes  to  the  evolving  standards. 


3.7  TESTING  AND  VAUOATION 

The  CALS  Test  Network  (CTN)  was  established  to  demonstrate  the  CALS 
standards,  test  their  effectiveness,  and  identify  needed  improvements  to  the 
standards.  Currerrtiy,  the  CTN  tests  only  the  CALS  data  interchange  standards. 
The  CTN  uses  naturally  occurring  tests  and  structured  tests.  After  the  test 
results  have  been  reviewed  and  approved  by  the  CTN,  the  test  reports  are  put 
on  the  CALS  Bulletin  Board  for  public  view.  The  CTN  testing  performed  by 
Industry  participants  and  lead  testbeds,  is  directed  by  the  CALS  Test  Network 
Office  reporting  to  the  Standards  and  Technology  Division  of  the  CALS  ElO.  The 
lead  testbed  for  MIL-D-28000A  is  the  Carderock  Division  of  the  Naval  Surface 
Warfare  Center  (NSWC).  Joe  Gamer.  301  227-1533,  is  the  point  of  contact 

The  CTN  has  test  packets  for  testing  MIL-D-28000  Class  I  and  II.  which  currently 
need  to  be  upgraded  to  the  MiL-D-2800QA  version.  Test  cases  for  Class  V  are 
currently  under  development  The  CTN  does  not  have  test  packets  for  Classes 
III  or  IV.  the  main  contents  of  the  CTN  test  packets  are:  IGES  files  to  process 
into  the  CAD  system,  scripts  to  follow  in  creating  the  data  on  the  CAD  system  for 
subsequent  oufout  and  plots  to  show  the  expected  results.  The  test  results  from 
the  naturally  occurring  tests  are  called  'Quick  Short  Test  Reports"  (QSTRs)  and 
are  available  from  the  CTN  or  the  CTN  Bulletin  Board. 

A  CTN  report  describes  the  digital  data  exchange  between  General 
Dynamics/Bectric  Boat  and  Newport  News.  It  is  titled  "SEAWOLF  Digital  Data 
Transfer  Program:  implementation  of  IGES  for  the  Acquisition  of  a  Msqor 
Weapons  System",  CTN  Report  Number  91-004.  The  report  is  a  good  example 
of  the  use  of  IGES  in  the  development  of  a  major  weapons  system  platform. 


3.8  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS 

AVAILABLE 

1.  ASME  Y14.26M  -  1989,  Digital  Representation  for  Communication  of 
Product  Definition  Data. 

(Copies  of  ASME  Y14.26M  may  be  ordered  from:  The  American  Society 
of  Mechanical  Engineers,  345  East  47th  Street  New  York,  N.Y.  10017. 

OR 
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American  National  Standards  Institute,  1430  Broadway,  New  York,  N.Y. 
10018.) 

(ASME  Y14.26M  was  adopted  by  OoO  on  22  December  1989.  DoO 
activities  may  order  ASME  Y14.26M  from:  Department  of  Defense  Single 
Stock  Point.  Commanding  Officer,  Naval  Publications  and  Forms  Center 
(NPFC),  5801  Tabor  Avenue,  Philadelphia,  PA.  19120.) 

2.  CALS  T est  Network  Handbook,  July  1 991 . 

3.  CALS  Test  Network  MIL-D-28000  Class  I  IGES  Reference  Illustration 
Packet 

4.  CALS  Test  Network  MiL-D-28000  Class  II  Reference  Drawing  Packet 

(Copies  of  CTN  Reports  and  test  padtets  are  avalable  free  of  charge 
from:  Cathy  Murphy.  AFLC  LNSC/SBC.  Area  C,  Building  89.  WPAFB,  OH 
45433-5000.) 

5.  Initial  Graphics  Exchange  Specification  (IGES)  Version  5.1  (September 
1991). 

(Copies  of  the  IGES  5.1  may  be  ordered  from:  the  National  Computer 
Graphics  Association  (NCGA),  Administrator,  IGES/PDES  Organization, 
2722  Meriiee  Drive,  Suite  200,  Fairfax.  VA.  22031.  Or  call  NCGA 
Technical  Services  and  Standards,  Nancy  Rower,  703  698-9600 
extension  325.) 

6.  M1L-D-28000A.  Digital  Representation  For  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application  Protocols. 


7.  MIL-HDBK-59A  Department  of  Defense  Computer-Aided  Acquisition  and 
Logistics  Support  (CALS)  Program  Implementation  Guide. 

8.  MIL-STD-1840B  Automated  Interchange  of  Technical  Information. 

(The  CALS  Specifications  and  Standards  are  available  free  of  charge 
from  the  CALS  Bulletin  Board:  703  321-8020.  For  a  nominal  charge,  the 
CALS  specifications  and  standards  nay  be  ordered  from  the  National 
Technical  Information  Service,  Springfield,  VA.  22161. 
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SECTION  4  -  STAMDARPggP  QPMPRAI  I7PD  MAWiaJP  LAMQUAQE  <SQyU 
MIL4i-28Q0lB 

4.1  PURPOSE 

MIL>M-28001B  establishes  requirernents  for  the  digitai  interchange  of  technical 
publication  text  Data  prepared  in  conformance  to  MIL‘M'28001B  will  facttitate  the 
automated  storage,  retrieval,  interchange,  and  processing  of  technical  documents  from 
heterogeneous  data  sources. 

The  latest  draft  of  MIL>M-28001B,  prepared  by  OASO(P&L4  CALS  and  dated  5  January 
1993,  has  undergone  some  modification  and  has  been  approved  for  publication  by  30 
June  1993.  The  draft  specifications  should  not  be  used  fw  acquisition  purposes  urrtii 
released  as  a  formal  specificatior\. 

The  CALS  standard  MIL-M-28001B  is  tfie  DoD  implementation  of  the  international 
startdard  ISO  8879  'Standard  Generalized  Markup  Language  (SGML)*.  Some 
familiarity  with  SGML  is  needed  to  understand  MtL-M-28001B. 

The  CALS  SGML  standard  defines  both  a  methodology  and  a  high  level  computer 
language  for  document  representation.  It  provides  a  coherent  and  unambiguous 
grammar  and  syntax  for  describing  whatever  a  user  chooses  to  identify  within  a 
document  regardless  of  the  type  of  document  or  the  nature  of  the  document's  text  and 
provides  a  formal  markup  procedure,  also  independent  of  system  and  output 
environments  for  this  purpose.  The  definition  of  the  document's  structure  or  content  in 
terms  of  'elements*,  their  'attributes',  'entities*,  and  otiier  components  is  a  called 
'Document  Type  Definition  (DTD)*.  A  DTD  defines  the  structure  or  content  of  a  specific 
class  of  documents. 

'SGML  markup*  (or  an  'SGML  instance”)  consists  of  unfonnatted  text  with  inserted 
SGML  tags'  which  correspond  to  the  elements  and  attributes  of  the  DTD.  These  tags 
identify  elements  of  the  text  (e.g.,  titles,  paragraphs,  tables,  footnotes)  defined  in  the 
document's  DTD.  The  'marked  up*  document  (or  SGML  instance)  can  than  be  'parsed* 
using  special  software  to  determine  if  the  document's  tagging  coriforms  to  the  DTD. 

UnHke  MIL-M<28001A  which  contained  the  DTD  for  documents  conforming  to 
MIL-M-38784B  and  12  DTDs  based  on  that  DTD,  MIL-M-28001B  will  not  contain  any 
DTDs  to  be  used  for  delivering  data  to  the  Government  Like  MIL-M-28001A, 
MIL-M-28001B  will  provide  the  so>calied  'template*  DTD  in  apperrdix  A.  Its  chief 
function  is  to  serve  as  a  toolkit*  for  the  construction  of  DTDs  by  providing  SGML 
coding  that  can  incorporated  or  modified  in  DTDs  being  developed.  The  template  DTD 
also  provides  a  set  of  elements  and  attributes  for  use  in  new  DTDs. 

A  'declaration  subset*  is  used  to  define  a  new  DTD  in  terms  of  changes  to  an  existing 
DTD.  The  implementation  of  the  changes  in  a  declaration  subset  results  in  a  complete 
and  different  DTD  for  the  corresponding  military  specification.  The  use  of  such 
'dectaration  subsets*  in  creating  new  DTDs  this  way  actually  allows  tighter  control  over 
the  number  of  distinct  DTDs.  WNie  DoD  wishes  MIL-M-28001B  to  be  implemented  in  a 
wide  variety  of  applications,  OoD  is  also  quite  concerned  with  the  uncontrolled 
proliferation  of  DTDs. 


4 


1 


New  DTDs  must  be  developed  for  all  applications  of  automated  technical  publications 
for  which  existing  CALS  DTDs  are  inadequate.  New  DTDs  should  be  constructed  using 
those  elements  and  attributes  of  the  template*  DTD  as  defined  in  Appendix  A  of 
MIL-M-28001B  whenever  possible.  This  Appendix  provides  general  guidance  for 
development  of  DTDs.  The  DTD  for  a  given  class  of  documents  such  as  technical 
manuals  will  either  be  provided  in  the  governing  specifications  for  such  documents  or 
else  be  completely  spewed  within  the  specification. 

4.2  APPUCATIONS 

The  development  of  those  CALS  DTDs  contained  in  earlier  versions  of  MiL>M-28001 
and  based  on  the  DTD  for  MiL*M-38784B  conforming  documents  was  a  coordinated 
effort  of  the  Navy,  Army,  Air  Force,  and  Industry.  MIL-M-38784B  has  been  superseded 
by  MtL*M-38784C,  and  the  DTD  for  documents  conforming  to  MIL-M-38784C  is 
provided  in  appendix  B  of  MIL-M-38784C.  in  addition,  numerous  other  DTDs  were 
deveiooed,  including  those  DTDs  developed  by  ttie  Air  Force  under  the  Technical 
Manual  Specifications  Standardization  (TMSS)  program,  and  a  Work  Package  DTD 
developed  for  Naval  Air  Systems  Command  (NAVAIR).  These  DTDs  will  be  included  or 
referenced  in  the  appropriate  functional  specifications. 

Currently,  MIL-M-28001B  is  concerned  with  the  digital  interchange  of  paper-based 
manuals.  However,  efforts  are  underway  to  define  the  digital  interchange  of 
‘paperless*,  i.e.,  screen  medium  technical  publications.  A  draft  specification, 
MIL-D-87269,  uses  SGML  to  specify  a  revisable  data  base  for  the  support  of  interactive 
electronic  technical  manuals. 

4.3  ARCHITECTURE 

MIL-M-28001 B  is  composed  of  the  following  six  sections  and  3  appendices: 

Section  1  •  SCOPE  Defines  the  scope  of  MIL-M-28001  B  with  respect  to 
establishing  requirements  for  the  digital  data  form  of  page-oriented  technical 
publications. 

Section  2  -  APPLICABLE  DOCUMENTS:  Identifies  the  documents  upon  which 
MIL-M-28001  B  is  based. 

Section  3  -  REQUIREMENTS:  Defines  the  general  requirements  imposed  upon 
publications  prepared  with  respect  to  MIL-M-28001  B. 

Section  4  -  QUALITY  ASSURANCE  PROVISIONS:  Defines  contractual 
requirements  for  quality  assurance  of  supplies  and  services. 

Section  5  •  PACKAGING:  Defines  packaging  requirements  as  per  MIL-STD-1840. 

Section  6  -  NOTES:  Identifies  additional  capabilities  of  the  specification. 
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a.  Section  6.1  'Intended  Use*  outlines  the  multi-step  preparation  of  technicai 

publications  in  an  automated  SGML  support  environment 

b.  Section  6.4  "Baseline  Publication  Types*  addresses  the  various  aspects  of 

document  delivery  in  detail. 

c.  Section  6.5  "Publication  Management  and  Processing  Considerations' 

discusses  various  technical  issues  such  as  DTD  preparation  and  source 
file  configuration  control  relevant  to  publication  management 

d.  Section  6.5.3  "Bectronic  Review"  discusses  the  procedure  for  electronic  review 

of  documents  on  a  network  and  the  consolidation  of  these  comments  for 
possible  implementation.  This  is  a  new  addition  to  MiL-M-28001. 

e.  Section  6.5.4. 1  describes  the  methodology  of  partial  document  defivery. 

Appendix  A  -  TEMPLATE  DOCTYPE  FOR  TECHNICAL  DOCUMENTS  / 
MARKUP  TAGS:  Contains  the  following  significant  material. 

a.  Section  30  "Introduction'  provides  a  summary  of  the  SGML  grammar  arfo  syntax 

defined  in  ISO  8879  and  also  provides  the  SGML  Declaration  used  by 
the  MIL-M-28001B  implementation  of  SGML 

b.  Section  50  "Example  Doctype  For  Technical  Documents'  provides  a  general 

purpose  DTD  which  is  intended  to  be  used  as  a  tool  kit*  for  constructing 
DTDs,  rather  than  as  a  DTD  in  its  own  right 

c.  Section  60  "Aiphabetical  Listing  Of  Tag  Descriptions'  contains  descriptions  of  all 

elements  defined  in  the  template*  DTD. 

d.  Section  70  "Mphabetical  Listing  Of  Attribute  Descriptions'  contains  descriptions 

of  commonly  used  sets  of  attributes. 

Appendix  B  •  OUTPUT  SPECIFICATION:  Contains  the  following  significant 
material. 

a  Section  30  'Output  Specification  (OS)  Concepts'  briefly  defines  the  Output 
Specification  (OS)  concept 

b.  Section  40  'Key  To  Characteristics*  describes  the  use  of  the  Output 

Specification  characteristics. 

c.  Section  50  'Interchange  Format*  contains  the  Output  Specification  DTD. 

d.  Section  60  'Guidelines*  describes  in  detail  a  16  step  procedure  for  writing  a 

FOSI. 
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Appendix  C  -  LIBRARY  OF  AVAILABLE  CHARACTER  EhTTITY 
DECLARATIONS/UBRARY  OF  AVAILABLE  DATA  CONTTENT  NOTATIONS/UBRARY 
OF  AVAILABLE  REPLACEMENT  TEXT  ENTITY  DECLARATIONS/UBRARY  OF 
AVAILABLE  PUBLIC  TABLE  DECLARATIONS:  Contains  the  following  significant 
material. 

a  Section  30  'Character  Set  Entity  Declarations'  provides  the  ISO  sets  of 
character  entity  declarations  for  providing  characters  not  available  on  the 
standard  keyboard. 

b.  Section  40  'Data  Content  Notation  Declarations'  provides  data  content 
notation  declarations  for  'iges',  fa:^,  etc.  external  entities. 

c.  Section  50  'Replacement  Text  Entity  Dedarations'  provides  entity 
declarations  for  'boilerplate'  text 

d.  Section  70  'Math  Declaration  Set*  provides  element  and  entity 
declarations  for  mathematical  notation. 

e.  Section  80  'Bectronic  Review  Declaration  Set*  provides  element  and 
entity  dedarations  to  support  the  electronic  review  of  SGML>tagged 
publications. 

4.4  STATUS  AND  PLANNED  EXTENSIONS 

It  is  in  the  interest  of  both  DoD  and  industry  to  agree  on  the  widest  applicable  set  of 
conventions  for  the  preparation  and  interchange  of  publications  for  defense  and 
non-defense  use.  MIL-M-28001B  has  identified  applications  which  exceed  the  scope  of 
ISO  8879  and  which  provide  a  more  comprehensive  specification  for  the  interchange  of 
ASCII  data.  Such  applications  include  the  spedtications  for  an  Output  Specification, 
Electronic  Review,  and  Partial  Document  delivery.  These  specifications  represent  the 
chief  enhancemertts  of  the  MIL-M-28001  specification  achieved  by  the  'B*  version  and 
are  briefly  discussed  below. 

4.4.1  OUTPUT  SPECIRCAT10N 

In  order  to  format  an  SGML  source  file,  associated  formatting  information  must  be 
provided.  This  associated  formatting  information  must  define  formatting  characteristics 
such  as  a  page  model,  font  and  family  characteristics,  point  size,  indenting,  etc.  In 
addition,  these  formatting  characteristics  must  be  responsive  to  certain  SGML  tags.  For 
example,  a  'paragraph'  tag  may  trigger  a  change  in  the  line  leading  or  a  'chapter  title' 
tag  may  trigger  'bolding*  and  'center*  functions.  The  Electronic  Publishing  Committee 
of  the  CALS  Industry  Standards  Working  Group  formed  a  'MIL-M-28001  Output 
Specification  Ad  Hoc  Group*  to  develop  a  standard  language  for  providing  the 
associated  formatting  information  of  SGML  instances.  It  was  decided  to  use  SGML 
itself  for  this  purpose  and  provide  the  associated  formatting  information  in  the  form  of 
an  "Output  Specification*  (OS)  DTD.  Appendix  B,  Section  50  of  MIL-M-28001B  contains 
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the  CALS  paper  medium  OS  DTD. 


The  OS  DTD  defines  a  finite  set  of  formatting  characteristics  used  to  rigorousty 
describe  the  composition  processing  functions  to  be  perfomned  with  respect  \o  the  tags 
of  a  SGML  source  file.  A  Formatting  Output  Specification  Instance  (FOSI)  is  an 
instance  of  the  OS  DTD.  The  FOSt  defines  values  for  the  formatting  characteristics 
defined  in  the  OS  DTD  for  every  SGML  element  used  in  the  document  DTD,  taking  into 
account  every  context  in  which  the  SGML  element  has  a  unique  formatting 
requirement,  as  would  be  the  case  where  a  title  of  a  TM  chapter  is  formatted  differently 
than  a  title  of  a  TM  ‘subparagraph.  The  objective  of  the  FOSt  is  to  rigorousiy  define  the 
format  style  of  the  document  to  be  produced  from  the  SGML  tagged  source  file,  as 
required  by  the  appropriate  functional  specification  (MIL-M-38784C,  etc.). 

A  FOSI  should  be  developed  for  each  DTD  to  describe  all  default  formatting 
characteristics  necessary  to  c‘^mpose  and  pubfish  a  document  authored  according  to 
that  DTD.  The  FOSI  should  be  delivered  with  the  SGML  source  file.  Sirsce  ail  FOSIs  will 
be  written  with  respect  to  the  standard  OS  (paper  medium),  vendors  will  be  able  to 
develop  software  that  can  accept  and  process  FOSIs  and  interface  with  the  publishing 
software.  However,  though  desirable,  such  automatic  processing  of  a  FOSI  is  not  a 
requirement  of  MIL-M-28001B. 

4.4.2  ELECTRONIC  REVIEW 

Section  80  of  appendix  C  of  MIL*M>28001B  provides  a  mechanism  which  enables  an 
electronic  review  and  comment  capability  for  SGML  source  files.  This  capability  enables 
reviewers  located  in  diverse  envirorvnents  to  make  and  exchange  comments 
electronically  on  muitipie  copies  of  a  document  file  over  a  network.  The  comments  may 
then  be  sorted,  processed,  and  incorporated  into  the  document  by  the  file  "owner*. 

The  mechanism  for  electronic  review  of  SGML  source  files  consists  of  certain  SGML 
constructs  which  are  incorporated  into  a  DTD  for  a  given  document  type.  These  SGML 
constructs  have  been  defined  as  generically  as  possible  to  take  into  account  the  many 
kinds  of  reviews:  internal  contractor  reviews,  Government  reviews, 
contractorAaovemment  reviews,  specification  reviews,  etc. 

Plans  for  future  extensions  of  electronic  review  indude  both  a  CALS  graphics  comment 
capability  using  SGML  for  the  comments,  and  a  capability  to  link  SGML  text  and  CALS 
graphics  files  for  related  changes.  Efforts  will  also  be  made  to  develop  a  more  predse 
addressing  mechanism  for  indicating  location  within  document  elements  affected  by  a 
proposed  change. 

4.4.3  PARTIAL  DOCUMENTS 

Partial  document  delivery  is  used  to  transmit  source  SGML  data  either  as  an  interim 
deliverable  or  as  an  update  package  containing  data  for  a  document  that  has  been 
previously  delivered.  Its  purpose  is  to  minimize  the  retransmittal  of  unchanged  data  or 
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to  indicate  incomplete  data.  Partial  document  delivery  is  not  intended  to  address  the 
issues  of  page  integrity  or  fidelity,  nor  is  it  intended  to  include  specific  change  pages. 
The  intent  of  this  methodology  is  to  allow  the  delivery  of  certain  portions  of  a  source 
document  such  that  the  receiving  system  can  identify  the  location  of  the  information  in 
the  original  document  and  perform  the  appropriate  addition,  deletion,  or  replacement 
operatiorts.  Both  the  manner  in  which  this  is  accomplished  and  the  eff^  of  the  change 
on  composition  depends  on  the  receiving  system. 

4.4.4  CALS  SGML  REGISTRY/CALS  SGML  UBRARY 

One  of  the  Ad  Hoc  Groups  of  the  Electronic  Publishing  Committee  is  investigating  the 
requirements  for  the  development  and  maintenance  of  a  CALS  SGML  Library  (CSL). 

It  is  envisioned  that  a  CALS  SGML  Registrar  will  administer  the  CALS  SGML  Registry 
(CSR),  a  central  registry  office  where  DTDs  and  FOSIs  witl  be  registered.  The  CSR  wili 
maintain  a  CALS  SGML  Library  will  be  an  on-line  database  contair^ng  all  SGML 
elements  and  attributes  that  have  been  defined,  with  cross  references  to  DTDs  and 
governing  military  specifications.  It  is  anticipated  that  all  CSR/CSL  requirements  will  be 
specified  in  a  future  revision  of  MIL-M-28001. 

The  CALS  SGML  Registry  will  require  adherence  to  basic  guidelines  for  acceptance  of 
SGML  tags/attributes.  These  guidelines  include: 

•  Querying  the  CSL  for  a  suitable  registered  DTD  in  lieu  of 
developing  a  new  DTD 

•  Ilf  a  new  DTD  is  to  be  developed,  compare  tag  requirements  with 
the  tags  currently  registered  in  the  CSL  Utilize  ‘‘generic* 
elements  as  much  as  possible.  For  example,  the  requirement  for 
a  "group  assembly  parts  list*  can  utilize  an  existing  CSL  element 
■pi*  (parts  lisQ.  This  way,  the  CSL  should  not  contain  "redundant* 
elements,  i.e.,  different  tags  for  the  same  information. 

•  If  no  existing  CSL  tag  is  suitable,  develop  a  new  tag  and  submit  it 
to  the  CSR  for  acceptance  into  the  CSL  The  CSR  wili  require 
that  the  tag  be  unique  (i.e.,  no  existing  CSL  element  will  suffice); 
that  (if  possible),  a  generic  tag  name  be  used  to  fadlitate 
DoD-wide  use;  and  that  the  tag  name  satisfy  naming  conventions 
defined  by  the  CSR. 

4.5  ADVANTAGES  OF  CURRENT  SPECIRCATJON 

MIL-M-28001  B  provides  SGML  applications  or  "conventions"  that  can  be  applied  in  the 
automation  of  document  production  and  management.  These  applications  include  the 
Output  Specification,  Electronic  Review,  Partial  Document  Delivery,  and  the  "template" 
DTD  tagset  of  elements  and  attributes.  These  innovations  which  are  oriented  toward 
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OoO  and  industry  needs  will  provide  a  comprehensive  specification  for  the  interchange 
of  ASCII  data.  They  constitute  both  a  ^-sighted  adaptation  and  a  wide-ranging 
application  of  ISO  8879  to  the  rapidly  changing  technology  of  the  printing  and 
pubiishing  industry. 

4.6  IMPLEMENTATION  ISSUES 

MIL-M-28001  has  undergone  extensive  revisions  since  its  initial  pubOcation  on  26 
February  1988.  MIL-M-28CX)1B  contains  various  specifications  and/or  recommendations 
for  the  interchange  of  data.  Some  of  these  have  not  been  thoroughly  tested,  including: 

•  the  method  for  tagging  mathematical  equations 

•  the  sufficiency  of  OS/FOSi  to  describe  format  requirements 

•  the  linkage  of  SGML  source  files  with  graphics 

•  the  receipt  of  partial  'change  package”  documents  from 
contractors 

Currently,  there  are  no  tests  for  vendor  products  claiming  conformarKe  to 
MIL’M-28001.  Such  MiL-M-28001  product  conformance  testing  wW  depend  upon  the 
products  functioa  For  instance,  conformance  testing  of  SGML  parsers  entails  the 
correct  interpretation  of  ISO  8879.  Conformance  testing  of  'auto-taggers'  or  'authoring 
stations”  would  be  limited  to  determining  the  parseabiilty  of  the  instances  generated, 
and  again  would  involve  cooect  ISO  8879  interpretation.  With  very  few  exceptions, 
there  is  no  disagreement  regarding  the  correct  interpretation  of  ISO  8879. 

However,  conformance  testing  of  CALS  SGML  publisNng  systems  involves 
MiL-M-28001  compliance  but  MIL-M-28001  does  not  rigorously  define  system 
requirements.  For  example,  while  MIL-M-28001  specifies  the  requirements  of  a  FOSI,  it 
does  not  require  a  system  to  automatically  process  such  a  FOSI.  Therefore, 
MIL-M-28001  B  conformance  testing  of  a  publisNng  system  would  likely  be  limited  to 
tests  for  CALS  data  acceptance  and  valid  document  formatting. 

4.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

The  vendor  community  is  aware  of  the  evolving  nature  of  MiL-M-28001 .  Some  vendors 
are  waiting  until  the  standard  is  finalized,  wNie  other  vendors  are  undertaking  full 
implementations  at  the  present  time.  A  large  vendor  community  is  represented  on  the 
Electronic  Publishing  Committee.  For  the  CALS  environment,  vendors  supporting 
MIL-M-28001  should  not  'hard-code*  their  systems  to  process  only  a  single  DTD  or 
FOSI.  Certainly,  most  users  will  be  processing  a  variety  of  technical  publications  wNch 
must  conform  to  multiple  DTDs  and  will  require  a  system  that  can  be  configured  to 
adapt  to  new  and  changing  requirements  as  ^ey  arise. 

Currently  there  are  various  types  of  SGML  software  products  on  the  market. 
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These  include: 


•  SGML  parsers  which  conform  to  ISO  8879.  Such  parsers  check 
OTDs  for  conformance  to  SGML  grammar  and  syrrtax.  They  also 
check  document  instances  for  conformance  to  a  given  OTD.  They 
return  error  reports  on  errors  found  in  the  parsing  process.  Many 
other  SGML  software  packages  (e.g.,  SGML  editors)  come  with  a 
'built-in*  parser. 

•  SGML  authoring  and  editing  software  which  'understands*  the 
DTD  as  it  is  given.  Such  software  guides  an  author  through  the 
creation  of  a  document  not  requiring  the  author  to  type  in  the 
SGML  tags.  The  keyed-in  text  is  automaticaJiy  formatted  and 
displayed  (norvWYSIWYG)  on  the  screen. 

•  SGML  Publishing  systems  which  accept  an  SGML-tagged 
document  and  associated  graphics  and  compose  the  entire 
document  in  accordance  with  the  document's  format 
specifications,  whether  in  e  form  of  a  FOSI,  or  system-irrtemal 
'style-sheet*. 

•  Software  which  automatically  tags  an  ASCII  file  based  on 
format-driven  triggers.  Most  of  the  'structure*  type  tags  (for 
paragraphs,  lists,  etc.)  can  be  automatically  generated  without 
any  trouble.  However,  unless  the  software  is  very  sophisticated, 
the  'content*  type  tags  (for  cross  references,  equipment 
numbers,  etc.)  cannot  be  automatically  generated.  Content  type 
tags  are  very  important  in  data  base  applications.  This  *auto- 
tagging*  software  can  be  used  in  conjunction  with  media 
converters  to  translate  formatted  'system-dependent*  files  (I.e., 
*WordPerfect*)  into  SGML  files. 

4.8  STRUCTURE  OF  THE  DEVELOPMENT  ORGANIZATION 

The  Bectronic  Publishing  Committee  (EPC)  of  the  CALS  Industry  Standards  Working 
Group  (ISWG)  has  served  as  the  MIL-M-28001  development  organization,  responsible 
for  reviewing  industry  and  Government  comments  with  respect  to  the  standard.  The 
CALS  Digital  Standards  Office,  an  OSD  chartered  organization  located  at  Wright 
Patterson  Air  Force  Base,  Dayton,  Ohio,  is  responsible  for  publishing  and  managing 
MIL-M-28001. 

The  EPC  has  formed  7  Ad  Hoc  sub-committees  to  determine  and  specify  additional 
features  for  the  DOD  implementation  of  SGML  These  Ad  Hoc  Groups  are  tasked  with 
planning  the  implementation  of  the  EPC's  agenda  for  MIL-M-28001. 

Ad  Hoc  1  -  Change  Package 

Ad  Hoc  2  -  CALS  SGML  Library  (CSL)  and  CALS  SGML  Registrar 
(CSR) 
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Ad  Hoc  3  •  FOSi/Output  Spedfication  and  OSSSL  (Document  Style 

Semantics  Specification  Language) 

Ad  Hoc  4 '  Specification  Reorganization 

Ad  Hoc  5  •  Advanced  Data  Concepts  (lETM,  etc.) 

Ad  Hoc  6  -  Bectronic  Review 

Ad  Hoc  7  •  Oversite  Committee 

4.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS 

The  primary  SGML  reference  document  is  the  International  Organization  for 
Standardization  publication.  ISO  8879  'information  Processing  -  Text  and  Office 
Systems  •  Standard  Generalized  Markup  Language  (SGML)'.  This  is  the  authoritative 
source  for  SGML,  and  it  provides  the  most  general  description  of  SGML  All 
non-proprietary  SGML  implementations  are  based  on  the  meta-ianguage  defined 
thereia 

Additional  documents  providing  general  and  technical  background  Information  on 
SGML  are: 

(1)  'SGML  The  User^  Guide  to  iSO  8879'  by  Joan  M.  Smith  and  Robert 
Stuteiy  (John  Wiley,  1988)  -  chiefly  an  index  and  cross-reference  to  ISO 
8879. 

(2)  The  SGML  Handbook*  by  Charles  M.  Goldfarb  (Oxford  University  Press, 
1990)  •  esserttially  an  annotated  version  of  ISO  8879. 

(3)  'SGML  An  Author's  Guide  to  the  Standard  Generalized  Markup 
Language'  by  Martin  Bryan  (Addison-Wesley,  1988)  -  a  general 
irtroduction  to  SGML 

(4)  'Practical  SGML”  by  Eric  van  Herwijnen  (Kluwer  Academic,  1990)  • 
artother  general  irrtroduction  to  SGML 
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5.1  PURPOSE 

The  MIL-R-28002  specification  establishes  requirements  for  a  standard  interchange  file 
format  and  raster  encoding  scheme  for  raster  data.  MIL-R-28002  (Type  I  and  Type  II 
as  defined  in  NISTIR  88-4017)  was  first  issued  in  December  1988.  It  was  revised  by 
MIL-R-28002A  in  November  of  1990  and  again  by  MIL-R-28002B,  14  December  1992. 
This  specification  identifies  the  requirements  to  be  met  when  raster  data  represented  in 
digital,  binary  format  are  delivered  to  the  Government 

Raster  graphics  involves  the  digital  processing,  storage,  exchange  and  reproduction  of 
images.  This  technology  supports  the  binary  representation  of  a  two-dimensional 
image  as  an  array  of  picture  elements,  also  known  as  pels.  Each  pel  of  the  array 
contains  information  about  that  portion  of  the  image.  This  information  may  include  its 
lightness,  darkness,  gray-level  and  color.  The  quality  of  the  image  depends  directly  on 
the  density  of  pels  within  the  array,  also  known  as  resolution  density  or  pel  transmission 
density.  A  high  resolution  density  provides  a  high  quality  image,  but  at  the  e}q>ense  of 
higher  storage  costs.  Data  compression,  in  which  an  encoding  scheme  is  used  to 
represent  redundam  data  bits  of  irtformation,  can  alleviate  this  storage  problem  to  some 
extent  MIL-R-28002  restricts  such  compression  to  Group  4  encoding  as  defined  in 
Consultative  Committee  on  Telegraph  and  Telephone  (CCITT)  Recommendation  T.6 
(FIPS  PUB  150)  in  order  to  conform  with  devebping  industry  standards. 

MIL-R-28002  permits  two  types  of  digital  representation  of  raster  data,  called  Type  I 
and  Type  II  in  the  specification.  The  Type  I  file  format  is  used  for  raster  data  contained 
in  a  single  monolithic  block  of  compressed  data  and  is  called  untiled  raster  data  The 
Type  II  file  format  is  an  Open  Document  Architecture  (ODA)  document  (as  specified  by 
ISO  8613  ODA)  conforming  to  a  special  application  profile  for  raster.  Type  II  may  be 
tiled  raster  data  or  may  consist  of  a  single  compressed  block  of  data  as  in  Type  I,  but 
with  all  ODA  parameters  and  data  structuring  included. 

Tiled  raster  data  consists  of  an  ims^e  that  is  subdivided  into  non-overlapp'mg  regions 
known  as  tiles  where  each  tile  is  treated  as  a  separate  pel  array.  This  method  is 
especially  useful  for  mechanical  drawings  in  which  there  are  large  open  areas  of  space. 
Figure  5-1  shows  an  image  overiayed  with  a  grid  coordinate  system  to  produce  the  tiie 
subdivisions.  Within  a  single  image,  tiles  are  equal  in  size  and  their  dimensions, 
specified  in  terms  of  pels,  have  certain  limitations.  Tiles  can  be  compressed  ana 
manipulated  to  obtain  an  optimal  raster  file.  However,  it  is  possible  that  compression 
can  result  in  an  enlarged  set  of  data  ("negative  compression'^,  especially  in  busy  areas 
of  the  image.  Therefore,  compression  must  be  employed  with  care.  In  such  situations, 
an  optimal  raster  file  can  be  obtained  using  a  mixture  of  compressed  and 
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uncompressed  tiles.  MIL-R-28002  specifies  that  individual  tiles  be  digitized  and  the 
data  compressed  in  accordance  with  Group  4  encoding  defined  in  Recommendation 
T.6  (FIPS  PUB  150).  In  cases  where  negative  compression  occurs,  MIL-R-28002  allows 
transmission  of  the  raster  bitmap. 
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Rgure  5-1  Tiled  Raster  Graphics  Example 


Type  I  raster  data  interchange  is  intended  to  be  used  in  procuring  data  for  systems  that 
only  use  untiled  raster  data  representations.  Examples  of  such  systems  include  typical 
technical  documentation  systems,  the  Air  Force  Engineering  Data  Computer-Assisted 
Retrieval  System  (EDGARS)  and  the  Army  Digital  Storage  and  Retrieval  Engineering 
Data  System  (DSREDS).  A  set  of  graphics  attributes  specifying  the  details  necessary 
for  processing  and  reproducing  the  image  must  be  included  in  a  header  record  at  the 
beginning  of  the  raster  file.  These  attributes  ir;lude  the  size  of  the  original  image,  the 
scanning  resolution,  the  image  orientation  (portrait  or  landscape),  the  starting  position 
on  the  page,  and  the  spacing  between  the  pels  and  also  between  the  lines  containing 
the  pels.  These  attributes  are  used  in  reproducing  the  image  and  apply  to  both  Type  I 
and  Type  II  raster  datafiles. 

Type  II  raster  data  interchange  is  intended  to  be  used  in  procuring  data  for  systems  that 
need  the  flexibility  to  use  tiled  or  a  mixture  of  tiled  and  untiled  raster  data 
representations.  Tiled  representations  are  best  applied  in  systems  handling  large 
format  drawings  or  illustrations  typically  associated  with  engineering  design.  The 
subdivision  of  a  drawing  into  tiles  allows  the  use  of  only  those  portions  of  an  image 
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required  at  a  given  time  by  the  application.  This  can  result  in  reduced  requirements  for 
workstation  memory  and  display.  The  attributes  required  for  Type  I  are  also  required 
for  Type  II  data  and  are  encoded  in  the  ODA  data  stream  as  specified  by  the  ODA 
Raster  DAP  (explained  below).  For  Type  II  data,  additional  attribute  information  must 
be  included  to  cover  the  size  of  each  tile,  the  number  of  tiles  in  the  array  (image),  the 
method  of  tile  ordering,  and  the  method  of  tile  coding.  This  information  is  stored  in  the 
header  record  of  an  image  file  during  the  scanning  process  and  is  essential  for 
reproducing  the  image. 

5.2  TYPICAL  APPUCATIONS 

MIL-R-28002  was  created  for  the  storage  and  interchange  of  scanned  engineering 
dravtrings  but  applies  to  other  documents  as  well,  such  as  technical  manuals  and 
illustration  in  raster  form. 

Appendix  A  of  MtL-R-28002B  contains  the  Open  Document  Architecture  (ODA)  Raster 
Document  Application  Profile  (DAP).  The  DAP  specifies  an  interchange  format  suitable 
for  transfer  of  structured  documerrts  between  equipment  designed  for  raster 
processing.  The  documents  supported  by  the  Raster  DAP  are  based  on  the  paradigm 
of  an  electronic  drawing  or  illustration.  Such  documents  contain  one  or  more  pages. 
Each  page  consists  of  an  image  in  the  form  of  a  bi-tonal  raster  graphic  content  There 
is  no  restriction  on  the  minimum  size  of  the  image.  The  DAP  allows  large  format  raster 
documents  to  be  interchanged  in  a  formatted  form  in  accordance  with  ISO  8613  (ODA) 
summarized  in  Section  1 1  of  the  overview  document 

The  features  of  a  document  that  can  be  interchanged  using  the  Raster  DAP  fall  into  the 
following  categories: 

•  Page  format  features  •  these  deal  with  how  the  layout  of  each  page 
of  a  document  will  appear  when  reproduced; 

•  Raster  graphics  layout  and  imaging  features  •  these  deal  with  how 
the  document  content  will  appear  within  pages  of  the  reproduced 
document;  and 

•  Raster  graphics  coding  •  these  deal  with  the  raster  graphics 
representations  and  control  functions  that  make  up  the  raster 
graphics  content 

5.3  ARCHITECTURE 

MIL-R-28002  identifies  the  requirements  to  be  met  when  raster  data  represented  in 
digital,  binary  format  is  delivered  to  me  Federal  Government  This  specification 
identifies  the  storage  and  transmission  format  of  raster  data  and  tiling  conventions  for 
document  pages  and  large  format  engineering  drawings  interchanged  as  raster  images. 
All  digital  raster  data  files  complying  with  MIL-R-28002  shall  conform  to  either  the  Type 
I  or  Type  II  binary  formats  defined  in  the  specification. 
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As  specified  in  MIL-STD-1840,  a  set  of  graphics  attributes  specifying  the  details 
necessary  for  processing  and  reproducing  the  image  is  contained  in  a  header  record  at 
the  beginning  of  a  raster  file.  These  attributes  irtclude  an  indication  of  the  raster  data 
type,  the  size  of  the  originaJ  image,  the  scanning  resolution,  the  image  orientation 
(whether  it  be  portrait  or  landscape),  the  spacing  between  the  pels,  the  spacing 
between  the  lines  containing  the  pels  and  the  bit  ordering.  These  attributes  are  used  in 
reproducing  the  image  and  apply  to  both  the  Type  I  and  Type  tl  raster  data  formats. 

Type  I  data  is  CCITT  T.6  encoded  data  for  an  entire  scan  representation  enclosed 
within  MIL-STD-1840  header  informatioa  The  CCITT  T.6  encoding  of  raster  data  is 
defined  in  FIPS  PUB  150,  Telecommunications:  Facsimile  Coding  Schemes  and 
Coding  Control  Functions  for  Group  4  Facsimile  Apparatus.  Type  I  has  no  support  for 
tiling,  but  has  the  virtue  of  simplicity. 

Type  II  data  is  a  MIL-STO-1840  header  wrapped  around  an  ODA  document  as 
specified  in  the  ODA  Raster  DAP.  The  ODA  document  may  consist  of  a  single 
compressed  block  of  data  as  in  Type  I  or  it  may  be  tiled.  ODA  parameters  and  data 
structuring  must  be  included.  A  discussion  of  the  ODA  architecture  is  included  in 
Section  1 1  of  this  summary  document 

5.4  STATUS  AND  PLANNED  EXTENSIONS 

MIL-R'28002B  was  published  in  December  1992.  As  a  result  of  international 
harmonization  activities,  changes  were  made  to  the  March  1993  version  of  the  ODA 
Raster  DAP.  The  'application  comments*  attribute  will  now  consist  of  two  fields  to  be 
compatible  with  other  Internationa)  Profiles  and  the  value  for  the  *ODA  version* 
attribute  was  changed.  DoD  decided  that  these  changes  were  significant  enough  to 
warrant  an  amendment  to  MIL-R-28002B.  The  amendment  will  contain  changes  to 
Appendix  A  (the  ODA  Raster  DAP)  and  is  not  expected  to  impact  the  MIL-R-28002B 
implementation  of  the  DAP.  Therefore,  current  Implementations  of  MIL-R-28002B  will 
be  upwardly  compatible  with  the  amendment  This  amendment  is  expected  before  the 
end  of  the  1993  fiscal  year. 

The  National  Institute  of  Standards  and  Technology  (NIST)  is  planning  to  issue  the 
ODA  Raster  DAP  as  a  FIPS  PUB  by  the  end  of  1993.  Once  the  FIPS  is  in  place 
MIL-R-28002  will  no  longer  contain  the  ODA  Raster  DAP  as  an  appendix,  but  will 
reference  the  appropriate  FIPS. 

The  ODA  Raster  DAP  published  in  the  September  1992  OIW  Stable  Implementation 
Agreements  (Appendix  A  to  MIL-R-28002B),  was  presented  to  the  Profile  Alignment 
Group  for  ODA  (PAGODA)  for  consideration  as  an  International  Profile.  PAGODA 
delegations  agreed  to  propose  to  the  respective  workshops  that  a  specification  be 
developed  with  the  intent  of  achieving  a  proposed  Draft  International  Standardized 
Profile  (pDISP).  In  International  circles  a  Profile  is  called  an  Open  Document  Format 
(FOD).  The  ODA  Raster  DAP  became  pDISP  FOD1 12. 
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The  ODA  Raster  DAP  was  widely  ctrcuiated  among  the  respective  workshops  and 
comments  were  forwarded  to  the  OiW  ODA  SIG.  PAGODA  delegations  represent  the 
01 W,  Asia-Oceania  Workshop  (AOW),  European  Workshop  for  Open  Systems 
(EWOS),  and  CCITT  Study  Group  VIII.  PAGODA  has  requested  that  F0D1 12  allow  the 
512  tile  size  default  and  any  other  tile  size  for  greater  flexibility.  This  tile  size  change 
was  made  to  F0D1 12.  but  not  to  the  ODA  Raster  DAP.  Therefore  the  ODA  Raster  DAP 
is  now  a  subset  of  pDISP  F0D112.  This  profile  will  be  reviewed  using  the  International 
Profile  Progressive  Schedule  with  a  June  1994  projected  date  for  becoming  an 
International  Profile. 

5.5  AOVAHTAGES  OF  CURRENT  SPECIRCATtON 

MIL-R-28002  reflects  the  intent  of  OSD  to  use  existing  and  emerging  international 
standards  as  the  basis  for  implementation.  The  ODA  standard  allows  the  storage  of 
complex  documents  containing  graphics  and  textual  information  and  the  production  of 
compound  documents  using  facsimile  technology.  ODA  was  dted  for  Type  II  raster 
data  in  an  effort  to  ensure  that  raster  data  specification  efforts  align  with  evolving 
international  raster  imaging  standards  and  promote  interoperability  with  other  raster 
data  formats  used  in  the  open  document  architecture  standard. 

5.6  IMPLEMENTATION  ISSUES 

The  development  of  Type  I  data  capabilities  has  been  evolving  for  some  time  and, 
consequently,  has  reached  a  stabilized  state.  CALS  Test  Network  (CTN)  digital  raster 
data  interchange  testing  for  Type  I  data  has  aided  many  present  and  potential  DoD 
contractors  in  their  efforts  to  develop  hardware  and  software  that  are  technically 
capable  of  accomplishing  MIL-R-28002  Type  I  Interchanges.  In  particular,  the  CTN 
Engineering  Data  Transfer  Test  with  EDMICS  using  MIL-R-28002  (May  1992)  reported 
that  MIL-STD-1840A  tapes  generated  by  EDCARS  and  DSREDS  were  successfully 
converted  from  CALS  (MIL-R-28002)  to  EDMICS  native  format  and  visually  displayed 
on  EDMICS.  in  principle,  this  demonstration  supported  the  viability  of  tri-service  data 
interoperability  via  CALS  media  CTN  has  published  several  test  reports  that  describe 
Type  I  testing  results  for  a  variety  of  vendor  implementations.  NIST  has  begun  Type  I 
conformance  test  development 

Type  II  data  on  the  other  hand,  is  a  much  newer  and  more  complex  environment.  ODA 
implementors  maintain  that  a  detailed  understanding  of  the  ASN.1  Basic  Encoding 
Rules  (required  by  ODA)  is  not  required  to  understand  MIL-R-28002B  Type  II.  A  vendor 
or  user  need  only  implement  the  Raster  DAP  not  the  entire  ODA  standard  to  achieve  a 
MIL-R-28002  Type  II  implementation.  Users  may  employ  a  library  of  ASN.1  routines  to 
avoid  having  to  ^lly  understand  encodings  at  the  bit  or  byte  level.  The  National  Institute 
of  Standards  and  Technology  (NIST)  report  NISTIR  5108,  "Raster  Graphics:  A  Tutorial 
and  Implementation  Guide",  is  an  excellent  resource  for  those  needing  a  better 
understarxling  of  MIL-R-28002  and  how  to  implement  it.  This  tutorial  examines  the 
technical  issues  facing  an  implementor  of  the  raster  data  interchange  format. 
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ANSI/AIIM  MS53  1993  is  also  a  useful  aid  to  those  attempting  to  develop  OOA 
implementations. 

A  system  that  can  receive  (read)  and  output  (write)  MIL*R-28002B  Type  I  and  Type  II 
datau  will  be  considered  a  compliant  CALS  implementation.  The  internal  raster  data 
format  of  the  system  need  not  use  ODA.  Cost  comparisons  between  the 
implementation  of  data  translators  verses  designing  the  system's  internal  format  based 
on  ODA,  should  be  performed  to  determine  what  is  the  best  MIL-R-28002B  (Type  ll) 
implementation  strategy  for  each  Navy  raster  system. 

Future  systems  could  be  designed  based  on  ODA.  Navy  managers  should  carefully 
assess  Ihe  offeror's  knowledge  of  and  experience  with  ODA.  At  a  minimum,  an 
implementor  would  need  to  have  expert  knowledge  of  the  following  ODA  docummts  to 
avoid  the  government  expending  time  and  resources  in  offeror/contractor  ODA 
knowledge  and  experience  development  activities: 

NOTE:  The  1993  version  of  ISO  8613  is  expected  in  the  very  near 
future,  therefore  all  references  to  ISO  8613  will  become  the  1993  version 
and  not  the  1989  version. 

ISO  8613-1:  1989,  Information  processing  -  Text  and  Office  Systems;  Open  Document 
Architecture  (OD^  and  Interchange  Format  •  Part  1:  Introduction  and  General 
Principle. 

ISO  8613-2:  1989,  Information  processing  -  Text  and  Office  Systems;  Open  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  2:  Document  Structure. 

ISO  8613-7:  (to  be  published  in  1993),  Information  processing  -  Text  and  Office 
Systems;  Open  Document  Architecture  (OD/^  and  Interchange  Format  -  Part  7: 
Amendment  •  Tiled  Raster  Graphics  Addendum  to  ISO  8913,  Part  7. 

Telecommunication  Standards  Sector  (TSS)  Recommendation  T.417:  1993, 

Information  Technology  -  Open  Document  Architecture  (ODA)  and  Interchange  Formats 
•  Raster  Graphics  Content  Architectures. 

MIL-R-28002B,  14  December  1992,  MILITARY  SPECIFICATION,  RASTER  GRAPHICS 
REPRESENTATION  IN  BINARY  Format,  REQUIREMENTS  FOR. 

MIL-STD-1840B.  MILITARY  STANDARD,  AUTOMATED  INTERCHANGE  OF 
TECHNICAL  INFORMATION. 

Spielman,  F.E,  and  Sharpe  L.H.,  1993,  Raster  Graphics:  A  Tutorial  and 
Implementation  Guide,  NISTIR  5108,  Computer  Systems  Laboratory,  NIST. 

5.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

The  Electronic  Imaging/Compression  Committee  (C.13.7)  of  the  Association  for 
Information  and  Image  Management  (AIIM)  has  developed  a  standard,  ANSI/AIIM 
MS53  1993,  'Standard  Recommended  Practice  -  RIe  Format  for  Storage  and 
Exchange  of  Images  -  Bi-Level  Image  RIe  Format  Part  1',  that  specifies  a  file  format 
for  the  exchange  of  bi-level,  electronic  images.  MS53  is  considered  a  subset  of  the 
ODA  Raster  DAP.  but  it  does  not  allow  for  the  tiling  of  raster  images.  This  standard  has 
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been  developed  to  encourage  the  use  of  OOA  by  the  United  States  image  technology 
community  and  to  provide  a  much  needed  standard  bi-level  image  file  format.  It  is  seen 
as  an  introductory  tool  for  users  and  implementors  of  OOA,  ASN.1  and  ODA  Raster 
DAP  applications  requiring  MIL-R-28002  Type  II  untiled  data.  MS53  is  AIIM's  attempt  at 
a  'cookbook'  approach  to  the  exchange  c  ^'-levei  electronic  images  using  ODA  with 
ASN.1  encoding. 

The  Navy  Automated  Document  Martagement  And  Publishing  System  (ADMAPS) 
utilizes  MIL-R-28002  Type  I  during  the  document  scanning,  raster  image  display  and 
raster  image  storage  processes. 

During  1991  the  CALS  Test  Network  evaluated  the  CALS  data  interchange  utilities 
developed  as  a  part  of  the  Air  Force  EDCARS  and  Navy  EDMtCS  programs.  Both 
systems  were  found  to  be  capable  of  importing  and  exp(^ng  CALS  MIL-STD-1840 
tapes  containing  MtL-R-28002  Type  I  image  data. 

The  CTN  Raster  Test  Bed  at  the  Lawrence  Livermore  National  Laboratory  (LLNL)  and 
David  Taylor  Model  Basin,  CDNSWC  have  been  involved  with  the  testing  and  validation 
of  raster  image  data  provided  by  Industry  and  DOD. 

InterUnear  Technology,  in  support  of  LLNL  has  developed  a  Test  tool  called 
'ODATOOL*  to  evaluate  CALS  raster  image  data  formatted  according  to  the 
MIL-R-280Q2A.  CTN  has  tasked  InterUnear  to  update  the  ODATOOL  in  accordance 
with  MIL'R-28002B.  InterUnear  offers  commercial  products  to  write,  convert  and  read 
ODA  files.  At  present  only  the  Modular  Electronic  Document  Information  Solution 
(MEDIS)  systems  by  InterUnear  Technology  support  MtL-R-28002  Type  I  and  II. 

5.8  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

The  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  Office  of  the  Department 
of  Defense  sought  suggestions  from  the  large  document  raster  irtdustry  for  a  standard 
interchange  file  format  and  encoding  scheme.  An  ad-hoc  industry  Tiling  Task  Group 
(TTG)  was  formed  and  developed  a  draft  standard  based  on  the  Consultative 
Committee  on  Telegraph  and  Telephone  (CCITT)  Recommendation  T.73. 

Subsequent  to  the  approval  of  T.73,  CCITT  began  collaborating  with  the  International 
Organization  for  Standardization  (ISO)  and  developed  a  technology  based  upon  the 
concept  of  a  compound  document  which  was  to  replace  the  current  facsimile 
environment  International  Standard  (IS)  8613,  which  defines  the  Open  Document 
Architecture  (ODA),  was  the  result 

The  TTG  modified  its  file  format  into  a  Document  Application  Profile  (D.\P)  for  ODA  and 
wrote  a  proposed  addendum  to  ISO  8613,  Part  7  -  Ra  ,  Graphics  Content 
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Architectures,  in  order  to  insert  the  minimal  mechanisms  needed  to  support  tiling.  OAPs 
are  developed  by  groups  such  as  the  TTG  to  satisfy  special  user  requirements. 

The  development  of  a  DAP  specific  to  image  applications  has  been  driven  by 
requirements  for  the  interchange  of  CCITT  facsimile  documents  and  DOO  CALS 
applications  for  scanned  images  and  engineering  drawings.  The  DAP  continues  to  be 
further  developed  by  the  ODA  Special  Interest  Group  (SIG)  of  the  OSI  Implementors' 
Workshop.  The  ODA  Raster  DAP,  is  the  result  of  this  group's  efforts. 

Stable  Implementation  Agreements  for  Open  Systems  Interconnection  Protocols:  Part 
23  ODA  Raster  DAP,  September  1992.  is  the  Raster  DAP  that  is  Appendix  A  of 
MtL-R-28002B.  It  is  the  result  of  the  continuing  efforts  of  the  ODA  SIG.  The 
development  of  this  DAP  was  performed  in  liaison  with  the  DOD  CALS  Office,  David 
Taylor  Model  Basin  CDNSWC,  and  the  ad-hoc  Tiling  Task  Group. 
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SECTION  6  ■  DIGrTAL  REPRESENTATION  FOR  COMMUNICAT1QH  ,QE 

ILLUSTRATION  DATA:  COMPUTER  GRAPHICS  METAHLE  fCGMI  >  MIL-D.28QQ3 

6.1  PURPOSE 

The  Military  specification.  MIL-0-28003,  'Digital  Representation  of  Illustration  Data 
Computer  Graphics  Metafile  (CGM)*,  specifies  an  application  profile  of  the  international 
and  U.S.  standards  for  CGM  and  certain  spe^c  additional  requirements.  The 
Computer  Graphics  Metafile  standard  (ISO  8632)  is  a  pubfished  International  Startdard 
(ISO  8632),  an  American  National  Standard  (ANSI  X3.122),  and  a  Federal  Information 
Processing  Standard  (FIPS  128).  The  CGM  standard  is  being  developed  and 
maintained  through  a  coordinated  effort  of  ISO  SC24  and  ANSI  X3H3.  The  U.S.  and 
international  standards  are  identical. 

The  overall  intent  of  the  CGM  standard  is  to  provide  the  lowest  level  of  drawing 
functiortality  required  to  capture  and  reproduce  a  picture,  in  a  way  that  is  portable 
across  applications  and  devices.  The  CGM  standard  specifies  two-rimension^  vector 
graphics  data  interchange,  in  a  file  format  that  can  be  created  independently  of  device 
requirements  and  translated  into  formats  needed  by  specific  output  devices,  graphics 
systems,  and  computer  systems. 

A  metafile  is  a  device-independenL  application-independent  storage  format  for  the 
exchange  of  the  data  that  makes  up  a  picture  ('picture  data').  The  metafile  definition  in 
ISO  8632  includes  a  definition  of  output  primitives  and  attributes  that  may  be  used  to 
compose  an  illustration,  but  in  an  intentionally  under-specified  semantics  (meaning). 
This  was  done  to  accommodate  a  wide  range  of  ewsting  systems,  and  to  make  the 
standard  more  adaptable  to  the  requirements  of  diverse  applications  and  users.  Three 
CGM  encodings  meet  different  needs,  but  all  may  be  interchanged  without  loss  of 
information.  The  binary  encoding  facilitates  rapid  graphic  data  processing.  The 
character  encoding  is  compact  and  transportable.  And  the  dear  text  encoding  is  human 
readable  and  editable. 

ISO  8632  CGM  is  an  upwardly  compatible  standard  format,  developed  in  three  versions 
that  offer  steps  in  capability.  Version  1  includes  elements  of  ISO  8632  CGM:  1987. 
Version  2  is  also  based  on  ISO  8632:1987,  but  adds  capabilities  through  Amendment 
1:1990.  Version  3  incorporates  ISO  8632:1987,  Amendment  1  and  Amendment  3:1991 
which  has  resulted  in  ma^or  increases  in  capabilities  that  are  represented  by  ISO/IEC 
8632:1992  the  current  version  of  the  CGM  standard.  ISO/IEC  8632:1992  provides  a 
clear  definition  of  Version  1,  2  and  3  metafiies. 
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The  CGM  application  profile  specified  by  Military  Specification  MIL-D-28003  adopts 
FIPS  128  and  defines  additional  requirements.  MIL-D-28003  defines  an  application 
profile  for  the  delivery  of  two-dimensional  picture  descriptions  of  illustration  data  that 
are  vector  or  mixed  vector  and  raster,  delivered  in  the  digital  format  of  Computer 
Graphics  Metafile.  MIL-0-28003,  first  published  20  December  1988.  was  superseded 
by  MIL-0-28003A  published  15  November  1991.  Amendment  1  to  MIL-D-28003A  was 
published  14  August  1992. 

MIL-D-28003A; 

•  Indudes  Version  1,  Version  2,  and  Version  3  of  ISO  8632. 

•  Indudes  Type  0  (monochrome).  Type  1  (grayscale)  and  Type  2  (full  color)  all 
based  on  DoD  usage. 

•  Defines  CGM  application  profile  requirements  that  address  the  first  of  several 
dasses  of  conforming  basic  metafiles,  a  conforming  bcsic  metafile  generator, 
and  both  a  minimum-level  and  a  publication-level  conforming  basic  metafile 
interpreter. 

•  Spedfies  requirements  on  CGM  generators  and  interpreters  to  provide  control 
over  the  creation  and  parsing  (validation)  of  conforming  metafiles,  and  to 
remove  Implementation  dependencies  that  might  preclude  predictable  (i.e., 
unambiguous)  interchange  of  metafiles. 

•  Defines  defaults  for  interpreters  where  these  are  not  specified  by  the  standard. 

•  Limits  encodings  to  binary.  Character  and  clear  text  are  prohibited. 

•  Uses  ISO  registered  line  types  (10  additional  line  types  are  added  as  specified 
in  ANSI  Y14.2M-1979). 

•  Uses  ISO  registered  hatch  styles  (18  additional  hatch  styles,  commonly  used  in 
drawings,  are  added). 

•  Resolves  a  common  indeterminacy  in  CGM  color  usage. 

•  Corrects  known  errors  in  the  CGM  standard. 

•  Allows  metrically  equivalent  fonts  to  be  substituted  for  the  Hershey  font 
specified  by  the  CGM  standard. 
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6.2  TYPICAL  APPUCATIONS 


The  MIL-D-28003A  is  intended  for  use  in  computer  graphics  applications  in  the 
following  situations: 

•  A  graphics  metafile  is  maintained  at  a  central  facility  for  a  decervtralized  system 
that  employs  graphics  devices  of  different  makes  and  models  that  must  utilize 
the  data 

•  A  graphics  metafile  is  required  to  preserve  picture  data  when  conversion  or 
migration  from  one  graphics  system  to  another  is  necessary  and  the  two 
systems  are  not  necessarily  compatible. 

•  A  graphics  metafile  is  intended  for  information  interchange  between  a  source 
system  and  a  target  system  that  are  not  necessarily  compatible. 

FIPS  128  in  conjunction  with  MIL-D-28003  should  be  used  when  the  representation  of 
graphical  information  in  digital  form  is  to  be  used  in  technical  illustration  and 
publications,  and  when  the  use  of  a  general-purpose,  graphical  interchange 
mechanism  is  required. 

ISO  8632  CGM  is  the  recommended  standard  to; 

•  View  the  image  on  a  wide  variety  of  devices,  with  different  characteristics  (such 
as  color  and  resolution),  where  the  set  of  devices  may  not  even  be  known  at  the 
time  the  metafile  is  generated; 

•  Enhance  the  picture  before  viewing  the  final  image;  and 

•  Compose  or  overlay  several  drawirtgs  into  a  single  picture  for  viewing. 

6.3  ARCHITECTURE 

The  CGM  standard  (ISO  8632-1987)  (FIPS  128),  ■Comp'Uter  Graphics  Metafile  for  the 
Storage  and  Transfer  of  Picture  Description  Information*  is  composed  of  4  parts.  MIL-D- 
28003A  utiiizes  Part  1  and  Part  3  of  the  standard's  four  part  architecture. 

Part  1  -  Functional  Specification  -  defines  the  functions  of  the  CGM,  independent  of 
any  encoding.  It  also  includes  responses  for  the  standard  and  design  requirements 
and  design  criteria 

Part  2  -  Character  Encoding  -  defines  an  encoding  of  the  Part  1  functionality  in  a 
format  that  conforms  to  ISO  code  extension  rules,  it  is  intended  to  provide  an 
encoding  of  minimum  size,  and  may  be  used  for  transfer  of  pictures  through 
networks  that  cannot  support  binary  transfer  of  data 
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Part  3  •  Binary  Encoding  -  defines  an  encoding  of  the  Part  1  functionality  that  is 
intended  to  not  require  any  other  effort  to  generate  and  interpret  on  many  systems. 

Part  4  -  Clear  Text  Encoding  •  specifies  an  encoding  of  the  Part  1  functionality  that 
can  be  created,  viewed,  and  edited  with  standard  text  editors.  This  encoding  is 
appropriate  for  networked  systems  that  support  only  text  file  transfer. 

6.4  STATUS  AND  PLANNED  EXTENSIONS 

MIL'0*28003,  first  published  20  December  1988,  was  superseded  by  MIL-D-28003A 
published  15  November  1991.  Amerxlment  1  to  MIL-0-28003A  was  published  14 
August  1992.  MIL-D-28003A  provides  capabilities  that  are  in  keeping  with  ISO  8632 
(FIPS  128).  An  Amendment  2  to  MIL-D-28003A  is  being  proposed  by  the  industry 
Steering  Group/Drawirtg  and  Graphics  Committee,  that  will  include  metafile 
descriptions,  clarification  of  restricted  text,  order  of  precedence  and  rules  for  profiles. 
The  overall  intent  of  this  amendment  is  to  permit  the  majority  of  CGM  software  procured 
under  MIL-D-28003  to  meet  the  requirements  of  MIL-D-28003A. 

Due  to  the  close  coordination  of  the  U.S.  and  international  CGM  standardization  efforts, 
there  is  a  move  to  make  CGM  Application  Profiles,  MIL-D-28003A  being  one  of  these, 
into  intematior^ai  Standardization  Profiles.  If  this  is  approved,  the  international 
community  will  make  changes  and  compromises  to  the  former  CGM  Application  Profiles 
such  as  the  CALS  CGM  AP. 

As  previously  stated,  ISO/IEC  8632:1992  is  the  newly  published  version  of  the  CGM 
standard  and  includes  capabilities  from  ISO  8632:1987,  Amendment  1  and  Amendment 
3.  In  particular,  Addendum  3  to  ISO  8632  CGM  is  targeted  towards  making  CGM  more 
applicable  to  the  CALS  environment  It  includes  the  following  capabilities; 

•  Advanced  2D  graphics  (curves;  fine  control  of  line  appearance;  composite  line 
primitives;  user  defined  line  types,  hatch  styles  and  marker  types;  additional 
standardized  hatch  styles;  arbitrary  text  path;  filing  mechanism;  and  general 
linear  transformations). 

•  Improved  text  and  font  support  (providing  a  linkage  to  the  font  standard  ISO 
9541). 

•  Arbitrary  boundaries  for  clipping  and  shielding. 
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•  AdditionaJ  color  models  beyond  RGB  (CIE,  etc.)  are  handled  through  a  new 
value  COLOUR  MODEL.  This  is  a  result  of  alignment  with  the  ODA  Color  work. 

•  Additional  raster  graphics  (scanned  image)  capabilities  were  added  to  the  Tile 
Array  to  assure  it  will  be  able  to  accommodate  all  popular  industry  formats  (ODA 
Part  7,  CALS  28002,  TIFF,  generic  CCfTT)  without  forcing  serious  manipuiation 
of  the  already-compressed  data 

•  The  functionality  of  an  external  reference  to  ‘standard*  litx’aries  of  named 
symbols  is  provided. 

•  A  provision  for  designation  of  transparent  cells  in  Cell  Array,  Tile  Array,  and 
pattern  definition  elements  is  included. 

The  purpose  of  this  work  is  to  extend  CGM  to  fulfill  requirements  (especially  of  CALS) 
of  engineering  drawings,  the  preparation  of  graphic  arts  quality  presentation  materials, 
cartography,  and  technical  publishing. 

The  CGM  method  of  tiling  is  based  on  the  Tiled  Raster  Interchange  Format  (TRIF)  that 
has  been  developed  for  ISO  8613-7:  Information  processing  -  Text  and  Office  Systems; 
Open  Document  Architecture  (OD/^  and  interchange  Format  -  Part  7:  Amendment  - 
Tiled  Raster  Graphics  Addendum  to  ISO  8913,  Part  7.  This  method  is  based  on  the 
ODA  virork  and  is  compatible  with  the  ODA  Raster  DAP  in  MIL-R-28002B:  1992, 
MILITARY  SPECIFICATION,  RASTER  GRAPHICS  REPRESENTATION  IN  BINARY 
FORMAT,  REQUIREMENTS  FOR.  The  raster  tiling  method  in  CGM  Is  very  similar  to  the 
method  used  in  MIL-R-28002  and  therefore  one  can  easily  convert  between  the  two. 
The  addition  of  tiled  raster  capabilities,  based  on  the  Tiled  Raster  Interchange  Format 
(TRIF),  allows  for  the  encoding  of  large  raster  images  within  a  CGM  file. 

Amendment  4  to  ISO  8632  has  been  proposed  to  define  Rules  for  Profiles.  This 
amendment  includes  rules  for  profiles,  a  model  profile,  and  conformance  requiremertts. 
Possible  future  extensions  to  CGM  of  considerable  interest  to  CALS  include  the 
formulation  of  an  object  structured  grammar.  This  has  been  requested  from,  and  will 
be  of  major  use  to,  CGM  users  in  commercial  aviation  (intelligent  graphics);  CALS 
electronic  review  (review  comments  in  graphics  and  stronger  links  to  text);  and 
hypermedia  (smart  ot^ects  in  graphics  databases).  Another  possible  extension  includes 
an  amendment  to  add  "intelligent  graphics*. 

6.5  ADVANTAGES  OF  CURRENT  SPECIRCATION 

CGM  specifies  device-independent,  digitaliy-encoded  vector  graphics  data.  CGM  files 
are  easily  transferred  and  displayed  on  a  wide  variety  of  hardcopy  devices  (dot-matrix, 
ink-jet,  electrostatic,  and  laser  printers,  pen  plotters,  and  film  cameras).  CGM  files  can 
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a'so  be  easily  previewed  on  an  extensive  range  of  softcopy  terminals.  In  comparison  to 
Raster,  CGM  is  easily  modifiable,  generally  of  much  smaller  size,  and  not  dependent 
upon  resolution  of  the  output  device.  In  comparison  to  IGES  (2D  data),  CGM  is  faster 
to  interpret  and  display,  and  again  more  compact.  The  selection  of  which  of  the  CALS 
graphic  standards  (raster,  IGES,  or  CGM)  that  best  fits  the  application,  should  be  the 
result  of  the  thorough  examination  of  the  processes  involved  in  the  application. 

6.6  IMPLEMENTATION  ISSUES 

Although  MIL-D-28003  has  been  available  for  some  time,  vendors  have  not  fully 
implemented  it,  thereby  causing  confusion  among  users.  Vendors  who  state  they  are 
"CGM-conforming*  may  not  be  MIL-D-28003  conforming.  Some  vendors  actually  have 
a  problem  with  importing  and  exporting  the  same  image;  if  a  CGM  file  is  imported  and 
then  immediately  exported,  it  may  be  changed. 

The  National  institute  of  Standards  and  Technology  (NIST)  offers  two  CGM  Test 
services',  metafile  testing  and  generator  testing.  The  purpose  of  the  test  services  is  to 
determine  the  degree  to  which  the  metafile  or  CGM  generator  conforms  to  FIPS  128 
and  MIL-D-28003.  At  presenL  formal  validation  is  available  for  metafile  testing  (i.e. 
instances  of  CGM)  and  generator  testing.  A  certificate  of  validation  is  issued  for 
metafiles  or  generator  implementations  that  have  been  tested  and  are  in  compliance 
with  FIPS  128  and  MIL-D-28003.  CGM  interpreter  testing  is  planned  to  begin  at  the  end 
of  1993. 

CALS  Test  Network  (CTN)  has  been  testing  Version  1  CGM  interchange  for  several 
years,  but  has  only  recently  acquired  a  CGM  generator  library  that  will  permit  the 
construction  of  Version  2  and  Version  3  CGMs.  CTN  continues  to  work  closely  with 
NIST  and  the  CGM  standards  organizations  to  improve  the  standard  and  to  resolve 
implementation  issues. 

The  ISO  8632  CGM  Amendment  3  draws  heavily  from  the  Open  Document  Architecture 
(ODA)  Colour  Addendum.  The  ODA  colour  addendum  has  a  second  calibration  matrix 
wNch  CGM  Amendment  3  has  not  included.  This  may  cause  some  inconsistencies 
when  CGM  is  used  as  the  graphics  content  of  an  ODA  document. 

The  OSI  Implementors  Workshop  (OIW)  has  developed  an  ODA  profile  with  CGM 
content.  This  is  identical  to  Part  8  of  the  ODA  standard.  The  CGM  committee  has 
reviewed  this  profile  and  finds  It  significantly  flawed.  Several  rounds  of  commenting. 
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with  over  twenty  mayor  technical  problems  spelled  out,  have  not  sufficiently  changed 
this  ODA  profile  to  make  it  acceptable  to  the  CGM  committee. 


I 
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6.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


CGM  is  an  established  standard  and  has  successfully  been  added  to  the  list  of  input 
and  output  formats  for  off-the-shelf  products.  There  are  over  350  implementations  on 
most  hardware  platforms  (i.e,  DOS,  Windows,  UNIX  VMS,  Macintosh  and  OS/2). 
Portions  of  the  information  in  Figure  2  were  extracted  from  a  graphics  connectivity 
market  analysis  performed  by  ImageMark  Software  Labs,  1990.  The  majority  of  the 
presently  available  CGM  software  is  based  on  CGM  Version  1. 


IMPORT  I  EXPORT 


PRODUCT 

MANUFACTURER 

Applause  II 

Ashton-Tate 

Arts  &  Letters 

Computer  Support 

CADleaf* 

Cadberry  Technology 

Corel  Draw 

Corel  S)^ems 

Designer* 

Microgrstfx 

Draw  Applause 

Ashton-Tate 

DrawP^ect 

WordPerfect 

Freelance  Plus 

Lotus  Development 

Forreview  • 

ATC 

Graph  in  the  Box 

New  England  Software 

Graph  Plus 

Micrografx 

Graphics  Gallery 

Hewlett-Parkard 

GRAFPACK-CGM  * 

GRAFPACK-GKS  * 

Graphporter  * 

GSC 

Graphwriter  II 

Lotus  Development 

Harvard  Graphics 

Software  Publishing 

Interleaf  * 

Interleaf 

IGES  convers.  utilities 

IDA 

Lotus  123  Ver.  3.0 

Lotus  Development 

Manuscript 

Lotus  Development 

Metapict  * 

GSC 

Mirage 

Zenographics 

PageMaker 

Aldus 

Pixie 

Zenographics 

Superimage 

Computer  Associates 

Ventura  Publisher 

Xerox 

WordPerfect 

WordPerfect 

Output/Translator 

Application  (0/TA) 

System  One  Software 

CTS/Metaview 

CGM  Technology  Software 

MDC  CGM  Toolkit 

McDonnell  Douglas 

Figure  2  -  CGM  Vendor  Support 

The  **•  indicates  that  the  vendor  claims  to  support  MIL-D-28003,  but  not  MIL-D- 
28003A. 
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6.8  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

The  CGM  standard  is  being  developed  and  maintained  through  a  coordinated  effort  of 
ISO  SC24  and  ANSI  X3H3,  as  the  U.S.  and  international  standards  are  identical.  In 
addition,  the  Drawing  and  Graphics  Committee  within  the  NSIA  Industry  Steering  Group 
Standards  Task  Group  will  be  addressing  problems  and  missing  functionality  of  the 
drawing  standards  (MiL-0-28003,  MiL-R-28002.  MiL-D-28CXX)),  and  recommending 
additional  work  to  improve  those  standards. 

6.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

1.  ISO  8632,  Information  Processing  Systems  -  Computer  Graphics  -  Computer 
Graphics  Metafile. 

2.  Henderson,  L  and  Mumford,  A.:  The  Computer  Graphics  Metafile*  Butterworth 
Series  in  Computer  Graphics  Standards. 

3.  HerKierson,  L.  and  Mumford,  A.:  'Introduction  to  The  Computer  Graphics  Metafile* 
Butterworth  Series  in  Computer  Graphics  Standards. 

4.  NIST  CGM  Information  Pack  for  Testing  Conformance  to  the  FIPS  128  and  CALS 
CGM  Application  Profile,  NIST. 

5.  *How  the  CALS  Program  Should  Utilize  Computer  Graphics  Standards*  Rnal 
Report,  Dr.  Peter  Bono.  October  10. 1986,  NBS  43NANB615018. 

6.  Military  Specification  MIL-D-28003A,  Digital  Representation  For  Communication  of 
Illustration  Data:  CGM  Application  Profile  (CGM  AP). 
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SECTION  7  -  INTERACTIVE  ELECI  TiOWC  TECHNICAL  MANUAL  SPECIRCATTONS 

7.1  PURPOSE 

Interactive  Electronic  Technical  Manuals  (lETMs)  are  the  paperless  but  functional 
equivalent  of  conventional  paper-based  technical  manuals  and  wiU,  in  the  future, 
replace  some  of  those  paper  TMs  in  the  field.  The  purpose  of  these  specifications  is 
for  the  acquisition  of  lETMs  and  associated  support  data  bases  by  a  DoD  Program 
Manager.  The  use  of  automated  access  and  presentation  techniques  in  lETMs  is  such 
that  these  CALS  specifications  will  not  be  simple  extensions  to  the  paper-based  TM 
specifications  but  will  be  a  new  category  of  specification  as  part  of  the  CALS  program. 

7.2  TYPICAL  APPUCATIONS 

These  specifications  will  be  used  in  several  modes  to  secure  various  lETM  products 
such  as  the  revisable  source  data  base  for  the  lETM,  the  presentation  software  for  the 
lETM,  and  the  computer  readable  lETM  data  package  which  is  the  lETM  itself. 

The  Navy  is  assessing  the  applicability  of  lETMs  to  its  A/F-X  developmental  Advanced 
Tactical  Aircraft,  the  SPAWAR  FOS/IUSS,  and  to  the  AEGIS  surface  ships  and  their 
associated  weapons  systems. 

The  Air  Force  is  planning  to  conduct  large-scale  field  evaluations  of  lETM  applicability 
for  the  F-16  fighter,  JSTARS,  the  B-2  bomber,  and  the  F-22  Advanced  Tactical  Rghter 
Aircraft. 

The  Army  is  performing  lETM  tests  on  a  number  of  fielded  systems,  including  a  Contact 
Test  Set  for  the  M-1  Tank,  the  Hawk  missile  radar,  the  AH-64  helicopter,  and  the 
Avenger  missile. 

The  V-22  aircraft  Program  is  planning  the  use  of  lETMs  and  will  be  a  joint  effort 
invloving  the  Navy,  the  Marine  Corps,  and  the  Air  Force. 

7.3  ARCHITECTURE 

The  lETM  specification  suite  consist  of  the  following  three  lETM  Specifications; 

a  Milltarv  Specification  MIL-M-87266.  Manual,  Interactive  Electronic  Technical 
(lETM):  General  Content,  Style,  Format,  and  User  Interaction  Requirements  for. 
MIL-M-87268  provides  a  general  set  of  Content,  Style,  Format,  and  User- 
Interaction  requirements  to  be  cited  in  all  lETM  acquisition  actions. 
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b.  Militafv  Specification  MIl-D-67269:  Data  Base,  Revisable;  Interactive  Electronic 
Technical  Manuals,  for  the  Support  of.  MIL-D-87269  defines  requirements  for 
the  weaporvsystem-related  data  base  from  which  lETMs  or  View  Packages  are 
to  be  constructed.  The  data  base  elements  are  defined  using  SGML 

c.  Milttarv  Specification  MIL-Q-87270:  Quality  Assurance  (QA)  Program: 
Interactive  Electronic  Technical  Manuals  (lETMs)  and  Associated  Technical 
Information;  Requirements  for.  MIL-Q-IETMQA  d^nes  a  Contractor-executed 
Quality  Assurartce  Program  to  assure  the  preparation  of  high-quality  lETMs  by 
prime  weapon-system  Contractors  and  their  suppliers. 

Two  additiortal  specifications  are  needed  to  support  the  procurement  of  an  entire  lETM 
system.  While  the  drafts  are  not  ready  for  coordination  at  this  time,  they  will  include:  1) 
the  hardware  and  software  to  be  used  by  the  user  electronic  display  system  (EDS),  and 
2)  the  computer  readable  View  Package  (Ref.  5)  which  is  the  form  of  the  lETM 
extracted,  compiled,  and  electronically  formatted  for  direct  use  (i.e.,  'read")  by  the  EDS. 

The  architecture  and  use  of  the  specifications  are,  in  general,  as  follows: 

1 .  First  the  lETM  provider  must  develop  a  Quality  Assurance  Program  Plan  (QAPP) 
according  to  the  guidance  provided  in  MIL-Q-87270,  after  which 

2.  The  lETM  provider  is  contracted  to  build  and  maintan  a  revisable  lETM  Data  Base 
structure  conforming  to  MIL-D-87269  and  ttien  loaded  with  lETM  content  data 
conforming  to  the  requirements  of  the  Content  and  Style  sections  of  MIL-M-87268. 

3.  The  Provider  is  then  tasked  to  extract,  compile,  and  format  an  lETM  View  Package 
according  to  a  specific  View  Package  Specification  which  spells  out  the  functional 
requirement  for  the  lETM  as  well  as  the  predse  format  for  the  View  Package. 

4.  This  lETM  View  Package,  copied  onto  the  offidal  distribution  medium  by  the 
Government,  is  then  provided  to  the  end  user  who  views  the  lETM  on  an  lETM 
Electronic  Display  System  (EDS)  which  must  present  the  lETM  information  in 
accordance  with  the  Format  and  User-interaction  Sections  of  MIL-M-87268. 
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7.4  STATUS  AND  PLANNED  EXTENSIONS 


The  three  OoP  lETM  spedficalioris  have  been  developed  and  have  been  issued 
effective  20  vember  1992.  The  Tri-Service  Working  Group  for  lETMs  has  approved 
a  tentativ<=>  plan  to  revise  these  specifications  over  the  next  tfvee  years  and  to  develop 
handbooks  and  specifications  for  the  View  Packages  arxf  the  Electronic  Display 
System  (EDS). 


7.5  ADVANTAGES  OF  CURRENT  SPECIRCAHON 

True  integration  of  DOD  weapon-system  logistic-support  Technical  Information  (Tl) 
systems,  as  required  by  the  Computer-Aided  Acquisition  and  Logistics  Support  (CALS) 
and  Corporate  Information  Management  (CiM)  initiatives,  would  be  rendered  impossible 
by  the  continued  reliance  of  the  Services  on  paper-based  Technical  Manuals  (TMs)  for 
the  great  bulk  of  this  information.  The  solution  to  this  dilemma  has  been  to  introduce  a 
new  type  of  Technical  Manual  especially  developed  for  display  using  the  power  and 
convenience  of  the  personal  opmputer. 

Recommendations  to  employ  lETMs  throughout  the  DOD  are  based  securely  on 
RDT&E  carried  out  by  all  three  Services  during  the  1970s  and  1980s.  User  surveys 
within  the  DOD,  technological  analyses,  design  studies,  iaboralory  experimentation, 
and  operationally  realistic  tests  of  lETM  principles  have  been  carefully  performed. 
Measurable  field  results  show  not  only  that  the  great  majority  of  Service  technicians 
find  the  lETM  approaches  desirable,  but  that  mantenance  performance  is  significantly 
improved,  particularly  in  complex  areas  such  as  troubleshooting.  These  test  show  that 
the  performance  of  inexperienced  technicians  shows  significant  improvement  over 
performance  with  paper  TMs. 

7.6  IMPLEMENTATION  ISSUES 

These  lETM  Specifications  are  the  first  in  a  series  needed  for  full  lETM 
implementations.  Although  the  technology  required  for  adoption  of  lETMs  exists  today, 
full  exploitation  of  the  lETM  capability  requires  resolution  of  a  number  of  technica 
problems  over  the  next  few  years.  Examples  of  such  technica  issues  are: 

a  A  standardized  tri-Service  definition  of  user-interaction  (man-machine)  features 
most  useful  for  lETMs. 

b.  Improved  automation  of  processes  for  authoring  lETMs. 
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c.  Improved  techniques  for  Government  lETM  acceptance  testing. 

d.  Improved  computer-controlled  fault-isolation  processes. 

e.  improved  screen  display  of  large-scale  drawings  and  schematics. 


However,  the  most  pressing  issue  is  the  need  for  a  coordinated  DOD  lETM 
implementation  strategy  to  assure  Service-wide  acquisition  and  effective  use  of  the 
lETM  technology.  Such  a  Strategy  should  incorporate  the  following  componwits; 

a.  Establishment  of  Service  policies  for  lETMs 

b.  Iderrtification  of  requirements  for  an  lETM  Acquisition  and  Support  System 

c.  Designation  of  organizational  responsibility  for  lETM  acquisition  and  control 

d.  Plan  for  trartsition  from  paper  TMs  to  lETMs 

e.  Establishment  of  support  ROT&E  programs 

f.  Corrtiruied  improvement  of  lETM  Spedfications  and  Startdards 

g.  Coordination  of  existing  lETM  efforts  in  the  Services 


h.  Coordination  of  lETM  technology  and  support  systems  >vith  other  DOD 
Technical  Information  systems. 


7.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


The  lETM  Spedficatiorts  have  been  widely  distributed  among  Industry  and  have  been 
briefed  at  CALS  conferences  and  lETM  Working  Group  meetings.  All  three  Services, 
as  well  as  the  CALS  Standards  Industry  Task  Group,  have  contributed  comments  on 
the  specifications.  Several  large  Military  SupF^iers  have  developed  IR&D  programs  to 
support  lETMs.  In  the  past  there  have  been  few  commercial  products  to  support  the 
Specifications,  however,  with  the  formal  release  of  the  Specificatioris  late  in  1992, 
suppliers  of  lETM  authoring  and  presentation  products  and  support  are  expected  to 
greatly  increase  in  the  very  near  future.  Bridge  products  (i.e.,  migration  aids  from 
paper-based  publishing  sy^ems  to  lETMs)  will  also  emerge  in  the  form  of  modified 
Hyper-Text  viewing  software  and  add-on  products  to  conventional  automated 
publishing  systems  to  output  SGML-tagged  files  with  lETMDB  (i-8  >  MIL-D-87269) 
tagged  data 

7.8  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 


The  CALS  specifications  for  lETMs  have  been  developed  by  the  Tri-Service  Working 
Group  for  Interactive  Electronic  Technical  Manuals,  chartered  by  the  OSD  CALS  Office. 


The  David  Taylor  Model  Basin,  Carderock  Division  Headquarters,  Naval  Surface 
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Warfare  Center,  (CARDEROCK  DIV  NAVSURFWARCEN)  is  the  Navy's  Lead 
Laboratory  for  TechnicaJ  Manual  Automation  and  is  the  chair  of  the  Tri-Services 
Working  Group  on  lETMs.  DTMB  serves  as  the  primary  contact  with  the  Industry  CALS 
committees  relating  to  Automated  TechnicaJ  Manuals  and  was  the  creator  of  the  initial 
set  of  draft  specifications  for  lETMs.  OTMB  is  leading  this  effort  with  assistance  from 
the  Air  Force  (AFMC/ENC)  and  Army  (LOGSA)  Members  of  the  Tri-Service  lETM 
Working  Group. 


7.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

1.  Military  Specification  MIL-M-87268.  Manual,  Interactive  Electronic  Technical 
(lETM):  General  Corrtent,  Style,  Format,  and  User  Interaction  Requirements  for.  Tri- 
Service  Working  Group  for  lETMs.  20  November  1992. 

2.  Military  Specification  MIL-D-87269:  Data  Base,  Revisable;  Interactive  Electronic 
Technical  Manuals,  for  the  Support  Tii-Service  Working  Group  For  lETMs.  20 
November  1992. 

3.  Military  Specification  MIL-Q-87270:  Quality  Assurance  (QA)  Program:  Interactive 
Electronic  Technical  Manuals  (lETMs)  and  Associated  Technical  Information; 
Requirements  for,  Tri-Service  Working  Group  for  lETMs.  20  November  1992. 

4.  Jorgensen,  Eric  L  Draft  Handbook  MIL-HDBK-EDS{NAVY):  Electronic  Display 
System  for  Navy  Interactive  Electronic  Technical  Manuals.  David  Taylor  Research 
Center.  DTRC/TM-1 2-91/11.  July  1991. 

5.  Jorgensen,  Eric  L  Draft  Handbook  MIL-HDBK-IETMVP:  Preparation  of  View 
Packages  in  Support  of  Interactive  Electronic  Technical  Manuals. 
DTRC/AFLC/AFHRL  CDNSWC/TM'12-92/84.  July  1992. 
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HYTIME  flSO/lEC  Draft  Intemational  Standard  10744^ 

8.1  PURPOSE 

The  Hypermedia  Time-Based  Document  Structuring  Language  (HyTime)  is  a  standard 
language  for  representing  the  logical  structure  of  documents  with  requirements  for 
space  and  time  based  coordinates  and  addressing.  HyTime  is  based  on  SGML  (ISO 
8879),  and  uses  the  grammatical  and  syntactical  conventions  of  SGML  HyTime 
provides  the  capability  to  package  information  ok^ects  using  a  standardized  markup 
language  whose  structure  will  enable  non-sequential  access,  querying,  version  control, 
and  long-term  maintenance  despHe  system  evolution  or  migration. 

By  using  the  SGML/HyTime  standards,  the  application  designer  can  create  system 
independent  files  that  are  transferable  and  interoperable  across  dissimilar  computer 
applications.  HyTime  provides  architectural  forms  for  the  definition  of  SGML  element 
classes  in  SGML  Document  Type  Definitions  (DTDs).  HyTime  does  not  provide  a  DTD, 
as  such,  but  instead,  constitutes  a  meta-DTD  from  which  conforming  application  DTDs 
can  be  created. 

IHyTime  is  not  now  a  CALS  standard.  It  is  perceived  as  a  potential  standard  supporting 
future  interactive,  electronic,  hypertext  and  multi-media  CALS  applications. 

8.2  TYPICAL  APPUCATIONS 

The  HyTime  language  can  be  directly  applied  to  hypertext  (documents  that  enable 
multiple  access  paths)  and  multimedia  applications.  These  include  the  design  and 
encoding  of  information  for  Interactive  Electronic  Technical  Manuals  and  Portable 
Maintenance  Aids  (lETM/PMAs),  online  review  of  existing  documents  both  in  and  not  in 
neutral  formats,  and  the  creation  of  large  interoperable  hyperdocument  libraries  or 
design  data  bases. 

HyTime  has  potential  applications  in  the  areas  of  project  management,  enterprise 
process  design,  discrete  everrt  simulation,  and  music. 

8.3  FEATURES 

HyTime  is  designed  for  modular  application.  Features  of  the  language  which  are  not 
needed  for  an  application  need  not  be  supported.  Depending  on  which  features  are 
supported,  HyTime  provides: 

•  Location  addressing:  a  standard  way  of  encoding  a  stem-neutral  address  of 
any  information  object  or  any  part  of  an  information  object  within  or  external  to 
any  given  document  Addressing  may  be  by  name,  position,  or  semantic 
property. 
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•  Hyperlinking;  models  for  hyperlink  classes  independent  of  the  number  of 
oi^ects  linked  to,  and  the  context  of  the  link.  One  model  even  provides  for 
attaching  properties  to  information  objects  that  cannot  be  modified  or  over¬ 
written. 

•  Scheduling;  synchronization  and  alignment  of  information  objects  relative  to 
one  another.  Information  objects  are  positioned  within  everrts  on  the 
spatio-temporal  axes  of  a  finite  coordinate  space  (FCS).  The  axes  of  the  FCS 
can  be  related  and  can  be  named  to  match  the  cr^ext  of  the  application.  For 
example,  the  X  axis  can  represent  a  virtual  time  line  as  seen  in  a  project 
management  schedule  for  project  phases,  and  the  Y  axis  can  represent  the 
real  clock  time  as  seen  by  a  calendar. 

•  Object  Modification:  Ot^ect  modification  is  scheduled  by  HyTime  but  must  be 
applied  by  applicatiorvspecific  functions.  This  enables  the  scheduling  of 
rendering  instructions  in  other  notations,  e.g..  PostScript 

•  Event  Projection:  Events  may  be  scheduled  and  projected  onto  alternative  finite 
coordinate  systems  and  scaled  accordingly.  For  example,  if  a  graphic  in  a 
document  must  be  rendered  in  a  smaller  area  on  a  display  screen,  this 
projection  and  scaling  can  be  indicated  by  HyTime  notation. 

•  Parseabiiity:  HyTime  documents  are  parseable  by  SGML  applications;  parsing 
checks  for  correct  SGML  grammar  and  syntax  as  well  as  conformance  of  the 
instance  to  the  OTD. 


8.4  HYTIME  ARCHITECTURE  AND  MODULES 

The  modules  of  . HyTime  are: 

•  Base  Module:  includes  hyperdocument  management  facilities,  SGML, 
identification  fadlKies  for  replacing  HyTime-specific  identifiers  with  user-defined 
identifiers  with  provisions  for  name  collisions,  coordinate  addressing  for 
scheduling  dimensions,  positions  of  events,  and  document  locations  addressing 
by  positioa  There  is  optional  support  for  specifying  activity  tracking  policies  by 
an  activity  tracking  attribute  tfiat  is  part  of  the  SGML  docurnem,  and  for  other 
basic  utilities  used  to  declare  default  attribute  values  and  definition  tables. 
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•  Location  Address  Module:  includes  functionality  to  provide  addressing  of 
information  objects  without  a  unique  identifier  within  the  current  documents 
name  space.  Supports  addressing  by  coordinate  location  (discrete  dimensions 
of  arbitrary  universe),  semantic  location  (by  SGML  attribute  name  or  by 
notation-specific  address),  or  rtamespace  location  (SGML  entities  and  SGML 
elements  in  external  documents). 

•  Hyperlink  Module:  Uses  five  metadasses  of  hyperlinks  to  define 

applicatiorvspecific  hyperlink  elements  with  their  own  processing  semantics. 
The  link  classes  are: 

•  independent  links  can  have  any  number  of  lir^  ends  with  optional  end  terms 
used  as  text  or  icons  to  invoke  the  link, 

property  links  (two  link  ends  which  associate  an  attribute  name  and  value 
with  an  element), 

contextual  links  (two  link  ertds.  one  of  which  is  a  link's  own  location), 

-  aggregate  location  links  link  multiple  locations  and  treat  them  as  a  single 
location, 

•  span  links  allow  contiguous  information  to  appear  to  be  undivided  by  SGML 
markup. 

•  Finite  Coordinate  Space  Module  (FCS):  provides  for  scheduling  of  ot^ects  with 
optional  projection  and  modification  modules.  Event  schedules  define  the 
position  and  occurrence  of  objects.  O^ects  occur  in  an  FCS  as  the  contem  of 
an  event  An  event  is  a  conceptual  bounding  box.  Each  event  has  a  set  of 
dimension  specifications  for  its  position  and  extent  on  the  coordinate  axes  of  the 
FCS  in  which  the  event  schedule  appears.  The  FCS  coordinates  can  be 
expressed  in  the  terms  of  the  application.  Rnite  Coordinate  Spaces  can  be 
nested.  For  example,  if  a  project  schedule  is  modeled  as  processes  nested 
within  processes,  the  FCS  can  be  used  to  encode  this  nesting,  the  relationship 
of  time  changes  that  occur  within  a  process  and  the  effect  of  these  changes  on 
processes  within  which  it  is  nested. 

8.5  ADVANTAGES  OF  CURRENT  SPECIFICATION 

Users  of  HyTime-compliant  systems  can  incorporate  active  references  within 
documents  and  to  external  online  documents.  This  includes  referencing  to  non-HyTime 
documents.  HyTime  can  reference  documents  in  multiple  notation  languages,  e.g., 
IGES,  VHDL,  ODA,  etc.  HyTime  location  addressing  includes  the  capability  to 
reference  read-only  documents  which  is  crucial  to  incorporating  legacy  data 
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HyTime  provides  a  standard  way  to  represent  abstract  time  dependencies.  HyTime's 
representation  of  time  and  space  measurements  is  the  same  and  can  be  extended  to 
any  measurement  domain  with  any  number  of  axes. 


HyTime  does  not  restrict  the  potential  sets  of  applications  nor  the  application  design 
except  in  the  agreemertts  about  how  to  express  hyperlinks.  This  enabies  maximum 
interoperability  of  hyperdocuments  without  attempting  to  standardize  the  information 
object  notations  or  modifiers. 

8.6  ENHANCEMENTS  TO  THE  PUBUSHEO  STANDARD 

The  newest  and  most  significant  addition  to  between  the  HyTime  published  standard  is 
the  HyQ  query  language.  It  was  added  to  provide  an  alternative  user  interne 
(sanctioned  by  ISO)  not  only  to  HyTime  and  SGML  documertts  but  non-SGML 
documents  as  well  by  using  HyTime  features.  Some  of  the  recent  technical  changes  to 
the  published  standard  impact  the  Content  Data  Model  which  must  be  revised 
accordingly. 

8.7  IMPLEMENTATION  ISSUES 


Non-KlyTime  notations  used  in  scaling  factors  cannot  be  executed  by  a  HyTime  system. 
Such  notations  might  include  the  potential  for  asynchronous  interrupts  by  a  user. 


HyTime  has  been  created  by  the  ISO  X3V1.8M  committee  with  much  effort  and  time 
spent  anticipating  conceivable  applications.  However,  at  this  time,  there  are  no  full 
scale  commercial  applications  that  can  be  examined  to  determine  if  the  standard  is 
effective.  Some  vendors  are  currently  working  toward  incorporating  HyTime  features, 
but  as  of  yet,  even  simple  applications  have  not  been  shown  publicly.  (TechnoTeacher 
Inc.  demonstrated  a  HyTime  system  at  the  Grs^hics  Communication  Association  (GCA) 
Winter  TechDoc  '92).  The  draft  standard  is  new  and  no  automated  validating  HyTime 
engines  exist  Most  of  the  examples  in  the  literature  have  been  created  by  volunteers. 


8.8  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


Prominent  work  being  done  with  the  HyTime  standard  includes  that  being  performed  by 
the  Tri-Service  working  group  developing  specifications  for  an  Interactive  Bectronic 
Technical  Manual  (lETM),  use  of  the  HyTime  hyperiinktng  architectural  forms  in  the 
Content  Data  Model  of  the  Integrated  Maintenance  information  System  of  the  US  Air 
Force,  work  by  the  MHEG  committee  to  demonstrate  the  inclusion  of  compressed  video 
in  a  HyTime-compliant  document,  and  the  use  of  the  Document  Style  Semantics  and 
Specification  Language  (DSSSL)  to  provide  processing  semantics  for 
HyTime-compliant  applications. 
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A  Special  Interest  Group  (SIG)  was  created  to  support  the  hypermedia  community.  The 
SGML  SIGHyper  SGML  User^  Group  Spedai  Interest  Group  on  Hypertext  and 
Multimedia  is  chaired  by  Steven  R.  Newcomb,  Vice-Chairman  of  the  original  ISO 
committee  that  created  the  HyTime  standard.  SIGHyper  maintains  an  active 
membership  comprised  of  some  of  the  world's  leading  authorities  in  the  hypermedia 
field,  and  publishes  a  newsletter  containing  articles  on  the  use  of  HyTime. 

There  are  groups  studying  HyTime.  These  include  the  HyTime  Study  Group  at 
Washington  School  of  Medicine  and  the  CCITT  Study  Group  VIII  Working  Party  4; 
Document  Architecture,  Transfer  and  Manipulation. 

Workshops  and  seminars  on  HyTime  are  being  conducted.  Techno-Teacher  Inc.  of 
Tallahassee,  Ra  conducted  the  HyTime  Implementer^  Workshop  at  the  GCA  TechDoc 
Winter  '92  conference  in  Ft  Lauderdale,  Ra  Steven  DeRose  of  Bectrortic  Book 
Technologies  presented  the  draft  HyTime  standard  at  the  Hypertext  *91  Conference  in 
San  Antonio,  Texas. 

The  Davenport  Group  in  their  Draft  Advisory  Standard,  30  January  1992,  has  adapted 
a  subset  of  HyTime  architectural  forms  as  the  basis  for  Online  and  Printed  Technical 
Documents  (MANPAGES)  usually  supplied  by  UNIX  vendors  to  customers.  It  will  allow 
vendors  to  bundle  documents  from  a  variety  of  publishers  and  to  give  the  customers 
access  to  these  documents  via  one  or  more  independently  defined  interfaces. 

8.9  REFERENCE  MATERIAL 

SGML  SIGHyper  Newsletter;  Vol.  1  No.  1;  October,  1991,  c/o  TechnoTeacher  Inc., 
1810  High  Road,  Tallahassee,  Ra  32303. 

ISO  8879  Information  Processing  Standards  -  Text  and  Office  Systems  •  Standard 
Generalized  Markup  Language  (SGML). 

"Hypermedia  Standards:  HyTime  and  MHEG",  Brian  Markey,  Digital  Equipment 
Corporation.  From  the  Proceedings  of  the  CALS  &po  *91  sponsored  by  the  CALS/CE 
Industry  Steering  Group. 

"Interactive  Processing  of  Information  Objects",  Paula  Angerstein,  Computer  Task 
Group.  From  the  proceedings  of  the  CALS  Expo  *91  sponsored  by  the  CALS/CE 
Industry  Steering  Group. 

"The  Tri-Service  Interactive  Electronic  Technical  Specification",  Eric  L  Jorgensen, 
Department  of  the  Navy.  From  a  presentation  given  by  Eric  Jorgensen  at  the  CALS 
Expo  "91  sponsored  by  the  CALS/CE  Industry  Steering  Group. 
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"Integrated  Maintenance  Information  System  (IMIS)  Conterrt  Data  Model  (COM)",  Bryan 
K  Caporlette,  Armstrong  Laboratory  Logistics  Research  Division.  From  the  proceedings 
of  the  CALS  Expo  '91  sponsored  by  the  CALS/CE  Industry  Steering  Group. 

"The  'HyTime'  Hypermedla/Time-based  Document  Structuring  Language",  Steven  R. 
Newcomb,  Neill  A.  Kipp,  and  Victoria  T.  Newcomb.  Communications  of  the  ACM, 
November  1991/Vol.34,  No.11. 

"Standard  Music  Description  Language  (SMDL)",  Charles  F.  Goldfarb.  Committe  Draft 
international  Standard  ISO/IEC  CD  10743,  April  1  1991. 

"HyTime:  A  Standard  for  Structured  Hypermedia  Interchange",  Charles  F.  Goldfarb. 
CALS  Journal,  Summer  1992,  Vol.  1.  No.  2. 
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SECTION  9  -  EDtF  (ELECTRONIC  DESIGN  INTERCHANGE  FORMA-H 

9.1  PURPOSE 

The  Electronic  Design  Interchange  Format  (EDIF)  standard  (ANSI/EIA  548)  Is  a  file 
format  and  product  description  for  electrical/  electronic  application  data  files. 

EDIF  was  developed  by  the  Bectronic  Industries  Association  (EIA)  to  attack  a 
pervasive  problem:  the  excessive  diversion  of  CAD  engineering  manpower  In  order  to 
exchange  design  data  between  diverse  CAD  hardware  and  software.  It  was  estimated 
that  this  diversion  took  as  much  as  60%  of  a  project's  work  force.  Each  interfece  to 
other  CAD  systems  and  tools  had  to  be  carefuliy  investigated,  and  perhaps  changed, 
each  time: 

•  a  software  tool  was  upgraded  by  a  vendor, 

•  an  operating  system  was  changed,  or 

•  a  different  work  station  was  used. 

This  investigation  had  to  be  followed  by  meticulous  testing  to  ensure  that  the  irrterface 
continued  to  work  property.  Also,  each  time  a  user  obtained  a  new  CAD  package,  its 
interfaces  to  existing  tools  and  host  computers  had  to  be  carefuliy  checked  out  and 
maintained. 

EDIF  IS  a  neutral  electronic  design  interchange  data  format  With  the  use  of  EDIF  only 
one  version  of  a  design  library  must  be  written,  and  only  one  translator  -  to  a  neutral 
format  •  is  required.  EDIF  was  designed  to  address  all  concerns  shared  by  the 
electronic  design  community,  including  simulation  models,  schematics,  and  1C  layouts. 

9.2  TYPICAL  APPUCATIONS 

Integrated  Circuit  (1C)  vendors  use  EDIF  to  exchange  1C  mask  data  In  addition,  EDIF  is 
used  for  product  representation.  There  are  some  users  of  EDIF  for  PCB  library  and 
layout  archive  and  transfer. 

Many  EDIF  users  plan  to  use  VHDL  for  system  architectural  descriptions,  while 
proposing  to  convert  the  VHDL  gate  level  descriptions  into  EDIF.  This  conversion 
creates  a  link  from  the  higher-level  descriptions  to  the  lower,  more  physical, 
descriptions.  In  fact,  some  think  that  EDIF,  through  its  Behavioral  View  (which 
describes  system  behavior),  can  be  used  to  transform  models  written  in  a  hardware 
description  language  such  as  VHDL,  into  an  equivalent  description  in  another 
language. 


9-1 


9.3  ARCHITECTURE 


EDtF  features  and  keywords  support  both  the  design  and  the  manufacture  of  electronic 
systems.  EDIF  files  may  be  made  up  of  10  distinct  •views*  to  describe  the  different 
electronic  design  representations; 

•  Schematic  View  •  drawings  of  circuits. 

•  Nettist  View  -  interconnections  among  components. 

•  PCBLayout  View  •  physical  locations  of  components  and  interconnects  on  each 
layer  of  a  printed-circuit  board. 

•  MASKLayout  View  -  solder  mask. 

•  Symbolic  View  •  cell  outlines  on  IC  layouts. 

•  LogicModel  View  •  behavior  of  simple  gates. 

•  Behavioral  View  -  system  behavior. 

•  Graphic  View  •  logos  and  other  simple  graphics. 

•  Document  View  •  user  manuals. 

•  Stranger  View  •  experimental  descriptions  for  cases  where  the  other  views  are 
not  s^propriate. 

EDIF  files  must  be: 

•  computer-comprehensible 

•  hardware  vendor-independent 

•  non-proprietary 

•  easily  extended  and  parsed 

•  human-readable,  for  debugging 

EDIF  files  are  designed  to  be  hierarchical  data  structures,  made  up  of  cells.  Within  a 
cell,  a  view  must  be  able  to  include  representations  of  other  views  (e.g.,  a  Document 
View  might  contain  a  description  of  a  cell  that  is  defined  in  a  Schematic  View.) 

9.4  STATUS  AND  PLANNED  EXTENSIONS 

EDIF  V2.1.0  is  now  available  from  the  Electronic  Industries  Association.  This  version 
shows  work  by  the  Technical  Committee  and  Subcommittees  in  the  Schematic,  PCB, 
Test  and  Information  modeling  areas  and  is  expected  to  broaden  EDIF  design  data 
transfer  effectiveness.  EDIF  V2.2.0  and  V2.3.0  will  cover  PCB  and  Test  respectively. 


9-2 


An  EDiF  EXPRESS  information  model  is  also  under  development  Version  3.0.0  is 
planned  to  contain  more  Behavioral  View  enhancements  and  extensions  to  microwave 
desiga 

The  Electronic  Industries  Association  (ElA)  Ad  Hoc  CALS  Study  Group  reviewed  EDIF, 
along  with  VHOL,  IQES,  and  IPC,  a^  tabulated  the  information  elements  into  four 
types; 

•  Behavioral  Description 

•  Functional  Description 

•  Logical  Description 

•  Circuit  Definition 

These  elements  were  used  to  determine  any  overlap  between  the  standards. 

EDIF  was  recommended  to  be  used  in  the  following  areas: 

•  Common  data  elements 

•  Circuit  Performance  Description 

•  Component  Manufacturing  Description 

•  Component  General  Specification 

These  areas  will  be  added  to  MIL-STD-1840  and  MIL-HDBK-59. 

The  CALS  office  has  also  determined  that  the  drawings  required  by  DoD-STD-100 
(Drawing,  Engineering  and  Associated  Lists)  map  easily  onto  the  database  defined  by 
EDIF.  The  CALS  office  dtes  the  following  EIA  documents  that  relate  to  EDIF: 

•  Introduction  of  EDIF  (EIA/EDIF-1) 

•  EDIF  Schematic  User  Guide  (EIA/EDIF-2) 

A  Microwave  Technical  Subcommittee  is  proposing  a  Microwave  View,  enabling 
microwave  Computer-Aided  Design  (CAD)  tools  to  exchange  design  data  Another 
Technical  Subcommittee  is  looking  at  a  Computer-Aided  Software  Engineering  (CASE) 
View.  The  Test  Technical  Subcommittee  is  extending  EDiF  into  analog  testing,  and 
EDIF  is  being  mapped  to  PDES/STEP. 

9^  ADVANTAGES  OF  CURRENT  SPECIFICATION 

A  msyor  advantage  of  EDIF  over  many  CAD  formats  is  that  EDIF  may  be  used  to 
exchange  only  the  amount  of  data  necessary  and  agreed  upon.  Thus,  a  netlist  might  be 
defined  in  EDIF  and  sent  to  an  1C  foundry.  The  1C  foundry  might  return  an  EDIF  file 
describing  the  resulting  1C  layout.  The  users  are  not  obligated  to  interchange  schematic 
information  or  behavioral  information  if  not  desired. 

Traditional  1C  layout  exchange  standards  (including  IGES)  describe  geometric  data,  but 
they  do  not  specify  the  connectivity  between  components.  EDIF  provides  an  option  for 
describing  the  connectivity  as  an  integral  part  of  the  MaskLayout  View. 
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9.6  IMPLEMENTATION  ISSUES 


A  limitation  of  EDIF  is  that  it  falls  to  recognize  that  electrical  products  are  ultimately 
constructed  of  mechanical  objects.  EOiF  is  the  least  mature  of  aU  product 
representation  specifications,  and  is  not  integrated  with  the  IPC  Series  350,  VHOL,  and 
IGES  at  this  time. 

9.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

EOIF  has  gained  wide  industry  acceptance  within  specific  application  domains.  In  1988, 
at  the  International  Conference  on  Computer  Aided  Design,  two  major  electronic  design 
work  station  vendors  ->  Hewlett-Packard  and  Valid  Logic  Systems  -  demonstrated 
systems  loaded  with  schematic  capture  programs  and  other  software  that  supported  a 
common  EOIF  file  to  handle  schematic  exchanges. 

At  the  Design  Automation  Conference  in  1988,  six  CAO  systems  demonstrated  EDIF  to 
over  2000  engineers.  Schematics  on  one  workstation  were  broadcast  to  the  others.  The 
EDIF  User's  group  point  of  contact  is  Mr.  Suresh  Agrawal  (214/997-2055). 

The  EDIF  standard  is  being  mapped  to  PDES/STEP.  The  PDES/STEP  activity  is 
developing  POES  Application  Protocols  for  Electronics  that  include  a  teaming  of  the 
CAD  Framework  Initiative  (CFI),  EDIF,  and  PDES,  to  facilitate  CAD  integration  through 
product  data  An  integrated  CAD  shared  Product  Database  will  be  formed.  The  EDIF 
responsibilities  to  this  effort  are: 

•  Definition  of  broad  electronic  user  information  requirements 

•  Mapping  of  information  requirements  to  EDIF  syntax 

•  Extension  of  EDIF  syntax  to  support  information  requirements 

•  User  demonstrations 

CFI  will  be  defining,  designing,  and  prototyping  a  framework  for  CAD  integration,  while 
PDES,  Inc.  will  be  defining  broad  mechanical  user  information  requirements,  and 
refining  electronic  user  information  requirements  for  specific  domains  (e.g.,  PCA/PCB). 
These  will  subsequerttly  be  mapped  to  STEP. 

The  Navy's  RAMP  program  is  providing  a  translator  that  converts  the  schematic 
information  from  EDIF  format  into  an  MIL-STD-1840-conforming  RAMP  fileset  EDIF  is 
used  to  carry  not  only  the  circuit  schematic,  but  also  the  electrical  functionality  for 
passive  components  (such  as  resistors,  inductors,  and  capacitors). 
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A  PCB  application  guide  has  been  published  and  experimental  use  of  EDIF  for  PCB 
library  and  layout  archive  and  transfer  has  been  started.  Interchange  of  schematics  in 
EDIF  among  multiple  competing  vendor  systems  has  been  demonstrated  twice  (at  the 
1988  Design  Automation  Conference  <./id  at  the  Fourth  EDIF  Workshop  September 
1988).  Netilst  and  schematic  transfer  in  EDIF  are  common  today  due  to  vendor  support. 

9^  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

EDIF  is  being  developed  and  maintained  by  the  Bectronic  Industries  Association  (EIA) 
Technical  Committee.  It  was  originally  developed  by  engineers  representing  three 
integrated  circuit  companies  (National.  Motorola  and  Texas  Instruments);  three  CAE 
systems  houses  (Daisy  Systems,  Merttor  Graphics  and  Hesvlett-Packa^);  and  the 
University  of  California  at  Berkeley. 

0.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

1 .  CALS  Report,  Vol  2,  No.  8,  August  1989. 

CALS  Report,  Vol  4,  No.  8,  August  1991. 

2  'CALS  Architecture  Study',  Report  to  the  Joint  Logistics  Commanders  and 
Office  of  the  Secretary  of  Defense  CALS  and  EDI  Office,  Volume  1;  Report, 
June  30,  1991. 

3.  'An  Overview  of  Electronic  Data  Interchange  Standards',  SME  Technical  Paper 
MS89-178.  Standards  of  CIM  Conference,  Febaiary  21-23, 1989. 

4.  Dashman,  Eric  H.,  'A  VHDL-to-EDIF  Translator*,  The  Fourth  EDIF  User  Group 
Workshop  Digest  of  Technical  Papers,  EDIF  User  Group,  2222  South  Dobson 
Road,  Building  5,  Mesa,  AZ,  85202. 1988. 

5.  Gilman  Alfred  S.,  'Using  VHDL  and  EDIF  in  Concert*,  The  Fourth  EDIF  User 
Group  Workshop  Digest  of  Technical  Papers,  EDIF  User  Group,  2222  South 
Dobson  Road,  Building  5,  Mesa,  AZ,  85202, 1988. 

6.  Shahdad  Moe,  'An  interface  Between  VHDL  and  EDIP,  Proceedings  of  the 
24th  ACM/IEEE  Design  Automation  Conference,  1987,  pp  472-478. 

7.  Grout  Steve,  Martin  Marietta  Corporation,  'Lessons  Learned,  Developing  STEP 
Electronic  Applications',  CALS  Expo  *92. 

8.  Sneed  James,  'Conversion  of  Technical  Data  for  Printed  Wiring  Assemblies  into 
CALS  MIL-STD-1840  Standard  Digital  Data',  CALS  Expo  *92. 
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*9.  ‘Harmonizing  CALS  Product  Data  Description  Standards:  An  Evaluation  Report 
by  the  EIA  Ad  Hoc  CALS  Study  Group*. 

*10.  EDIF  Standard  EIA  •  548. 

*1 1 .  Introduction  to  EDIF  (EIA/EDIF-1). 

*12.  EDIF  Connectivity. 

*13.  EDIF  Application  Guide  •  for  Schematics  Transfer. 

*14.  EDIF  Schematic  User  Guide  {EIA/EDIF-2). 

*  Copies  of  references  9  through  14  may  be  ordered  from  the  Electronic  Industries 
Association,  2001  Pennsylvania  Ave.,  N.W.,  Washington,  DC  20006  (Mark  V. 
Rosenker,  EIA  Engineering  Department  202/457-4900). 
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SECTION  10  ■  VHSIC  HARDWARE  DESCRIPTION  LANGUAGE  rVHPU 

ANSl/lEEeiflZfi 

10.1  PURPOSE 

The  Very  High  Speed  Integrated  Circuit  (VHSIC)  Hardware  Description  Language 
(VHDL)  is  the  most  widely  used  hardware  definition  language.  Though  a  formal 
notation,  it  Is  both  machine  readable  and  human  readable,  and  it  supports  the 
development,  verification,  synthesis,  and  testing  of  hardware  desi^;  the 
communication  of  hardware  design  data;  and  the  maintenance,  mocBfication,  and 
procurement  of  hardware.  VHOL  is  a  generalized,  system-independent  language; 
designs  described  in  VHOL  can  be  interchanged  between  computer  systems  that  meet 
the  specifications  of  the  standard. 

Just  as  a  schematic  is  inifialty  a  design  tool  but  may  later  function  as  supporting 
documentation  for  the  product,  VHOL  is  primarily  a  design  language;  its  use  as  an 
interchange  format  is  a  second^  benefit  from  this  goal. 

VHDL  describes  three  different  ‘views'  of  the  model  being  designed;  (1)  the  behavioral 
view  -  an  algorithmic  description  of  the  model  (like  a  programming  iar^uage);  (2)  the 
structural  view  •  a  simple  netlist  description  of  the  component;  and  (3)  the  data  flow 
view  •  a  network  of  sigrials  and  transformers. 

10J2  TYPICAL  APPLICATIONS 

VHOL  provides  a  means  to  design,  document,  interchange,  simulate  and  debug  chip 
and  circuit  designs  in  a  non-proprietary  way.  VHOL  is  typically  used  for  top  down 
system  design,  full  custom  chip  design.  Appiicatlon-Spedfic  integrated  Circuits  (ASIC) 
library  development.  Programmable  Logic  Design  (PLO),  Reld-Programmable  Gate 
Arrays  (FPQA)  design,  validation  of  designs  b^ore  and  after  synthesis,  and 
deveiopment  and  debugging  of  model  code. 

As  an  example,  Intel  Corporation  is  in  the  process  of  selecting  a  suite  of  VHDL  design 
and  synthesis  tools  for  development  of  the  X86  dass  of  chips  and  other  advanced 
devices. 

10.3  SCOPE  OF  THE  STANDARD 

Modeled  on  the  Ada  programming  language,  the  VHDL  standard  is  made  up  of  the 
following  sections: 

•  Design  Entities  and  Configurations:  The  design  entity  is  the  primary  hardware 
abstraction  in  VHDL.  It  represents  a  portion  of  a  hardware  design  that  has  well- 
defined  inputs  and  outputs  and  performs  a  well-defined  function.  A  corrfiguration 
can  be  used  to  describe  how  design  entities  are  put  together  to  form  a  complete 
design. 
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•  Subprograms  and  packages:  Subprograms  define  algorithms  for  computing 
values  or  exhibiting  behavior.  Packages  provide  a  means  of  defining  these  and 
other  resources  in  a  way  that  allows  different  design  units  to  share  the  same 
declarations.  Since  VHDL  has  no  "goto*  construct,  subprograms  can  return  to 
the  calling  program  from  any  point  in  their  execution  (loops  may  also  be  exited 
at  any  poirrt). 

•  Types:  A  type  is  characterized  by  a  set  of  values  and  a  set  of  operations.  VHDL 
provides  for  strong  typing,  assuring  that  the  data  will  be  operated  on  only  in 
predetermined  ways. 

•  Declarations:  For  each  form  of  declaration,  the  language  rules  define  a  certain 
region  of  text  called  the  scope  of  the  declaration.  Each  form  of  declaration 
associates  an  identifier  with  a  declared  entity.  Only  within  its  scope,  there  are 
places  where  it  is  possible  to  use  the  identifier  to  refer  to  the  associated 
declared  entity;  these  places  are  defined  by  the  visibility  rules. 

•  Specifications;  Specifications  may  be  used  to  associate  additional  information 
with  a  VHDL  description  (a  previously  declared  entity). 

•  Names;  Names  can  denote  declared  entities,  whether  declared  explicitly  or 
implicHty;  objects  denoted  by  access  values;  subelements  or  slices  of  composite 
objects;  and  values  and  attributes  of  these  items. 

•  Expressions:  An  expression  is  a  formula  that  defines  the  computation  of  a 
value. 

•  Sequential  Statements:  The  various  forms  of  sequential  statements  are  used  to 
define  algorithms  for  the  execution  of  a  subprogram  or  process;  they  execute  in 
the  order  in  which  they  appear. 

•  Concurrent  Statements:  Concurrent  statements  are  used  to  define 
interconnected  blocks  and  processes  that  jointly  describe  the  overall  behavior  or 
structure  of  a  design.  Concurrent  statements  execute  synchronously  with 
respect  to  each  other. 

•  Scope  and  Visibility:  There  are  rules  defining  the  scope  of  declarations  and 
rules  that  define  which  identifiers  are  visible  at  various  points  in  the  text  of  the 
description. 

•  Design  Units  and  Their  Analysis:  The  overall  organization  of  descriptions,  as 
well  as  their  analysis  and  subsequent  definition  in  a  design  library,  is  built  on 
design  units. 
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•  Elaboration  and  Execution:  The  process  by  which  a  declaration  achieves  its 
effect  is  called  the  elaboration  of  the  declaration.  After  its  elaboration,  a 
declaration  is  said  to  be  elaborated. 

•  Lexical  Elements:  The  text  of  a  description  cor^sists  of  one  or  more  design  files. 
The  text  of  a  design  file  is  a  sequence  of  lexical  elements,  each  composed  of 
characters. 

•  Predefined  Language  Environment  There  is  a  predefined  envirorvnent  for 
VHOL  made  up  of  predefined  attributes  and  packages  that  ail  VHDL 
implementations  must  provide. 

10.4  STATUS  AND  PLANNED  EXTENSIONS 

VHDL  was  initially  adopted  as  IEEE  standard  1076  in  1987.  IEEE  requires  the  revoting 
of  all  standards  every  five  years,  so  in  1990  the  IEEE  PI  076  standards  group  began 
identifying  a  restandard-ization  effort  A  new  version  of  VHDL  (1992)  was  developed, 
including  alt  design  requirements  aixi  as  many  design  goals  as  possible.  VHDL  1992 
will  be  submitted  to  the  IEEE  Standards  Board  in  1993  for  approval.  New  features  of 
VHDL  '92  are: 

•  Deferred  Interface  Object  Mapping  •  configuration-binding  of  instance's  ports. 

•  Direct  Instantiation  •  Ux  design  entity,  configuration  declaration. 

•  Extended  Character  Set  -  8-bit  Roman  alphabets. 

•  Extended  Identifiers  •  allows  any  printing  character,  case  sensitive. 

•  Foreign  Language  Interface  -  allows  access  to  any  architecture  or  subprogram. 

•  Generalized  Aliasing  •  anything  named  can  have  an  alias. 

•  Groups  •  used  to  express  and  annotate  relationships. 

•  Hierarchical  Pathnames  -  used  for  assertions,  error  messages,  tool  navigation. 

•  Impure  Functions  -  can  access  global  signals  and  variables  with  different 
arguments,  return  value. 

•  Postponed  Processes  -  execute  just  before  time  changes  so  value  is  stable  at 
current  simulated  time. 

•  Pulse  Rejection  -  inertial  delay  is  defined  different  from  transport  delay. 

•  Regularized  Syrrtax  •  one  rule  for  bracketing  keywords. 

•  Revamped  RIe  I/O  -  can  be  opened,  closed,  read  from,  vwitten  to,  appended  to; 
not  upwardly  compatible  from  VHDL  1987. 

•  Shared  Variables  -  accessible  from  multiple  processes. 

•  Shift  and  Rotate  Operators  -  may  be  overloaded,  assume  MSB  is  sign  bit, 
predefined  for  arrays  of  bit  or  Boolean. 

Requested  Features  not  in  VHOL  *92  are: 

•  Extensions  for  analog  modeling 

•  Language  support  for  network-based  calculations  -  load-  or  fanout-based  delay 
calculations 
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•  Toot-spedfic  semantics  •  synthesis  semantics 

•  Variant  records 

•  Timing  model  extensions  (RFOs) 

•  Asynchronous  process  reset 

■  Unconstrained  subelemenls  of  composite  types 

•  User-defined,  single-valued  attrttnjtes 

•  Private  types  and  a  pseudo-random  number  generator. 

More  information  about  the  features  of  VHDL  *92  and  those  requested  but  not 
incorporated  may  be  found  in  "An  Introduction  to  VHDL*  by  Paul  J.  MencWnl  EDA 
Consultancy.  2  Davis  Drive,  P.O.  Box  13036.  Research  Triangle  Park,  NC  27709-3036. 

Rve  additional  projects  have  been  proposed  for  approval  by  IEEE 

•  1076.1  analog  extensiorts 

•  1 076.2  Standard  math  package 

•  1076.3  Standard  synthesis  package 

•  1076.4  standard  timing  methodology 

•  1 076.5  VHDL  Utility  Libraiy 

An  official  IEEE  interpretations  documertts  has  been  issued  "Sense  of  the  VASG*  to 
discuss  user-created  issues  and  their  resolutions.  There  is  also  interest  in  extending 
VHDL  to  allow  for  the  formal  verification  of  designs.  The  VASG  is  working  together  with 
the  chairman  of  the  IEEE  Design  Automation  Standards  Subcommittee  to  determine 
what  work  is  necessary  for  this. 

Under  the  Electricai/Bectronic  project  of  the  PDES.Inc.  and  the  National  Initiative  for 
Product  Data  Exchange,  there  is  an  activity  to  develop  STEP  Applications  that  can 
represenL  exchange,  and  use  information  for  test  integrated  diagnostics,  and  re¬ 
manufacture  of  printed  circuit  assemblies  and  line  replaceable  modules.  VHDL  and 
EDIF  will  be  used  to  perform  demonstrations  of  the  developed  models  with  CAD  and 
tester  environments  and  platforms. 

Other  VHDL  activities  within  the  National  Initiafive  for  Product  Data  Exchange  include 
maintenance  and  enhancement  of  the  standard  modeling  language. 

Extensions  to  VHDL  currently  underway  are: 

•  a  VHDL  information  model, 

•  a  standard  for  the  VHDL  Intermediate  Form 

•  a  standard  for  VHDL  model  interoperability 

•  a  standard  interface  between  VHDL  and  the  Electronic  Design  Interchange 
Format  (EDIF). 

Also  within  the  VHDL  framework  are  various  test  language  specifications  including 
WAVES,  FDL,  and  TRSL  WAVES  is  an  IEEE  approved  test  language  which  provides 
a  standard  representation  for  stimulus  and  response  data  in  support  of  the  design  and 


test  of  digital  devices.  Related  to  WAVES  is  the  proposed  IEEE  Fault,  Detection,  and 
Localization  (FDL)  and  the  Test  Requirements  and  Specification  Language  (T^SL). 
FDL  will  provide  a  standard  representation  of  the  diagnostic  information  for  digitai  units 
needed  in  the  test  and  design  automation  environment  TSRL  will  provide  a  standard 
representation  for  the  test  requirements  and  the  test  intents  information  needed  in  the 
design  and  test  automation  process. 

Other  IEEE  VHOL  efforts  include: 

•  Data  Book  -  define  an  electronic  data  book  capturing  component  information  in 
support  of  VHDL  usage. 

•  EDIF  Irrteroperability  *  ensure  that  VHDL  and  EDIF  are  able  to  interoperate  at 
the  Schematic  and  Netiist  Level 

•  Timing  Study  •  develop  a  uniform  way  to  represent  timing  at  the  'Network  Level* 
in  VHDL  models  so  back  annotation  can  be  done  in  a  standard  way. 

10  J  ADVANTAGES  OF  CURRENT  SPECIFICATION 

VHDL  is: 

•  A  standard,  unambiguous,  simuiatable  description  of  all  parts  of  electronic 
designs. 

•  A  technology>independent  way  to  use  functional  descriptions  and  automatically 
synthesize  new  devices. 

•  A  method  for  allowing  verification  of  a  design  through  simulation,  prior  to 
building  expensive  hardware. 

The  DoD  sees  the  documentation  of  VHSiC  designs  as  a  main  protection  against 
diminishing  manufacturing  sources.  This  same  documentation  will  be  used  to  generate 
test  system  software. 

10.6  IMPLEMENTATION  ISSUES 

The  1987  version  of  VHDL  Is  In  wide  use.  However,  the  1992  VHDL  Is  NOT  restricted 
to  upwards-compatibility  to  the  1987  VHDL  This  poses  problems  for  users  who  wish  to 
upgrade;  it  also  poses  problems  with  the  VASG,  who  must  maintain  the  older  version 
for  some  time. 

The  lack  of  availability  of  software  to  provide  formal  verification  of  circuit  designs  has 
been  a  problem.  Formal  verification  consists  of  a  variety  of  mathematical  techniques  for 
specifying  and  verifying  circuit  designs.  The  only  commercial  product  available  is  limited 
to  the  verification  of  the  functional  equivalency  of  synthesized  synchronous  VHDL 
designs  to  the  original  VHDL  description.  In  order  for  this  standard  to  be  used 
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effectively  for  CALS  interchange,  a  more  comprehensive  verification  process  must  be 
established. 

The  VHDL  Initiative  Toward  ASIC  Libraries  (VITAL)  Model  Development  Specification 
(Draft),  Version  2.0,  was  developed  to  promote  the  rapid  development  and  use  of  ASIC 
libraries  for  VHDL  design.  Developed  by  ASIC  vendors,  CAE  tool  vendors,  and  ASIC 
designers,  the  spec  addresses  this  group's  highest  priority  issues:  timing  accuracy, 
model  maintainability,  and  simulation  perfc^artce.  The  specs  include  an  appendix  that 
proposes  language  changes  that  would  significantiy  aid  in  developing  models  and 
providing  a  more  concise  description  of  certain  classes  of  designs,  as  well  as  aiding  in 
the  description  and  handling  of  timing  information.  The  proposed  chartges  are: 

•  Definition  of  a  modified  PROCESS  Design  Unit  •  support  for  truth  tables  and 
state  tables. 

•  Allow  dynamic  indices  in  Event  and  Last_Vaiue  for  composite  types 

•  Glitch  Detection  and  X  generation 

•  Previous^Everrt  attribute  •  to  help  determine  the  time  since  the  last  event 

•  Implicit  Timing  Model  •  standardizes  the  way  timing  is  represented  for  ASIC 
modeling. 

10.7  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 

The  1987  version  of  VHDL  is  widely  used,  and  the  standardization  efforts  have  been 
supported  not  only  in  the  U.S.,  but  also  in  Europe  and  the  Pacific  Rim.  In  June  1991, 
leading  CAD  vendors  formed  the  VHDL  International  Alliance  to  promote  VHDL  as  a 
standard.  The  formation  of  this  alliance  shows  strong  support  for  the  VHDL  standard 
from  many  of  the  major  vendors. 

Most  vendors  do  not  fully  implement  the  complete  standard,  but  only  a  subset  of  the 
standard.  This  can  cause  problems  with  interchange,  but  these  discrepancies  are  being 
overcome  by  most  vendors  as  they  approach  full  support  of  the  startdard. 

A  design  done  in  VHDL  will  include  functional  blocks  that  must  be  mapped  to  physical 
components;  this  implies  an  interface  vrith  EDIF,  IGES  and  IPC.  The  Electronic 
industries  Association  (EIA)  Ad  Hoc  CALS  Study  Group  studied  VHDL  along  with  EDIF, 
IPC,  and  IGES  and  recommended  the  use  of  VHDL  for  Digital  Functional  Descriptions 
and  for  System  and  Box  General  Specifications.  The  CALS  office  also  cites  the 
following  industry  applicatior  <  protocols: 

•  Commercial  Component  Model  Specification  (EIA) 

•  Blank  Detailed  Specification  (EIA) 

•  Timing  Module  Specification  (EIA) 

•  Engineering  practices  for  the  Quality  Assurance  of  Standard  Part  Models  from 
external  Sources  (EIA). 

MIL-STD-454,  which  contains  standard  general  requirements  for  Electronic  Equipment 
(Requirement  64),  calls  for  VHDL  model  delivery  for  Microelectronic  Devices. 
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The  VHDL  Technology  Group  has  developed  a  VHDL  developers  toolkit  that  runs  on  all 
the  major  VHDL  simulators.  This  provides  a  common  modelirtg  style  that  guararttees 
high  quality  VHDL  models.  In  addition,  they  were  selected  by  VHDL  International  to 
develop  a  vendor-neutral  test  suite  that  addresses  language  compliance  and 
transportability  issues.  The  test  suite  should  be  available  early  1994. 

Appendix  A  of  MIL-STD-1840B  contains  requirements  for  VHDL  and  describes  the 
format  and  content  preparation  instructions  to  be  used  with  VHDL  data.  This  appendix 
is  a  normative  part  of  the  standard.  It  includes  the  detailed  requirements  for  device 
design  and  test  documentation,  and  gives  the  documentation  forniat  required.  The  data 
packages  to  be  included  in  the  VHDL  data  file  consist  of  common  product  description 
elements,  behavioral  descriptions  of  digital  electronics,  logical  descriptions  of  digital 
electronics,  and  timing  descriptions.  MIL-STD-1840B  also  calls  out  the  industry 
application  protocol  EiA-AP-2229  -  Commercial  Compor^nt  Model  Specification. 

10.8  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

VHDL  was  initially  adopted  as  IEEE  stssidard  1076  in  1987.  The  VHDL  developers,  the 
VHDL  Analysis  and  Standardization  Group  (VASQ),  a  working  group  of  the  IEEE 
Computer  Society,  then  became  a  maintenarx^e  organizatioa  VASG  created  an  issues 
Screening  and  Analysis  Committee  (iSAC)  for  maintenance  problems;  they  identified 
approximately  250  issues  and  resolved  80  of  them.  Also,  a  1992  Steering  Committee 
was  formed,  for  the  next  version  of  VHDL  The  Steering  Committee  was  broken  into 
five  subcommittees:  Design  Requirements,  Design  Objectives,  Language  Design, 
Language  Documentation,  and  Language  Validation. 

With  the  standardization  of  VHDL  1992  (in  1993),  a  new  committee  will  take  the  place 
of  the  1992  Steering  Committee.  This  new  committee  will  be  named  the  Core  VHDL 
Oversight  Committee  (note  "Core*  as  opposed  to  extensions  to  the  language).  This 
committee  will  be  responsible  for  deciding  how  and  when  to  deal  with  the  design 
objectives  left  over  from  the  1992  standardization  effort,  and  will  also  continue 
restandardization  efforts. 

10.9  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

1.  Primary  Reference:  Paul  MenchW,  Paul  J.  Menchinl  EDA  Consultancy,  2  Davis 
Drive,  P.O.  Box  13036,  Research  Triangle  Park,  NC  27709-3036  (919/990- 
9506).  "An  Introduction  to  VHDL*. 

2.  Electronic  Engineering  Times,  June  17, 1991- 
Electronic  News,  July  22  1991,  /^gust  12, 1991. 

CALS  Report  Vol  3,  No  8,  August  1989. 
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3.  The  Future  Role  of  the  IEEE  VHDL  Analysis  and  Standardization  Group*,  S. 
Kroiikoski  and  J.  Mermet 

4.  'Harmonizing  CALS  Product  Data  Description  Standards:  An  Evaluation  Report 
by  the  EIA  Ad  Hoc  CALS  Study  Group*.  EIA,  Engineering  Department  2001 
Eye  St,  NW,  Washington.  DC  20006,  February  1989. 

5.  Product  Data  Exchange  Baseline  ActMties,  Vol  2.  Release  1 .  October  1992. 

6.  VHDL  initiative  Toward  ASIC  Libraries  Model  Development  Specification  (Draft), 
Version  2.0. 

7.  An  Overview  of  Electronic  Data  Interchange  Standards,  SME  Technical  Paper 
MS89-178. 

8.  The  IEEE  Standard  VHDL  Language  Refinement  Rationale  >  explains  the 
reasons  for  the  adopted  changes,  compared  to  VHDL  7.2  and  compared  to 
other  changes  that  were  proposed  but  not  adopted.  Available  from  Wright 
Aeronautical  Laboratories. 

9.  The  IEEE  Standard  VHDL  Tutorial  •  makes  extensive  use  of  real  examples  to 
present  the  language  in  terms  of  its  relevance  to  hardware  design  problems. 
Also  illustrates  how  information  expressed  in  EDIF  can  be  represented  within 
VHDL  Available  from  Wright  Aeronautical  Laboratories. 

10.  The  VHDL  User's  Manual  •  contains  a  VHDL  tutorial,  a  VHDL  reference  guide, 
examples  of  benchmarks  coded  in  VHDL  and  a  set  of  usage  scenarios  showing 
ways  in  which  the  VHDL  system  mi^  be  employed  to  perform  a  variety  of 
functions.  Available  from  Wright  Aerortautical  Laboratories. 

1 1 .  The  VHDL  Design  Analysis  and  Justification  •  discusses  key  language  design 
decisions  and  justifies  the  choices  made.  Discusses  similarities  and  differences 
between  Ada  and  VHDL  Available  from  Wright  Aeronautical  Laboratories. 

12.  IEEE  Standard  VHDL  Language  Reference  Manual,  IEEE  Std  1076* 
1987. Available  from  the  IEEE,  New  York,  NY. 

13.  IEEE  Standards  Interpretations:  IEEE  Std  1076-1987,  IEEE  Standard  VHDL 
Language  Reference  Manual,  IEEE  Std  1076/INT-1991.  Available  from  the 
IEEE,  New  York,  NY. 

14.  Draft  Standard  VHDL  Language  Reference  Manual,  IEEE  PI  076-1 992/B. 
Available  from  the  IEEE,  New  York,  NY. 
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11.1  PURPOSE 


1 1.1.1  Ovwall  Purpose  of  th«  Standard 

The  Open  Document  Architecture  (ODA)  standard  (ISO  8613)  was  developed  to 
fadiitate  the  interchange  of  structured  offiM  documents  (e.g.,  letters,  memos,  reports) 
among  various  devices  and  applicatiorts  by  defining  the  stricture  fi.e.,  iayouQ  and 
content  of  documents  in  an  OSI  interchange  environment  The  parts  of  the  document 
and  how  it  should  look  are  defined  and  included  with  the  document  The  Intematlorud 
Consultative  Committee  on  Telegraph  and  Telephone  (CCITT)  Recommendations  of 
the  T.410  series  are  technically  identical  to  ISO  8613. 

The  logical  structure  of  a  document  is  a  definition  of  the  document's  parts.  A  technical 
report  is  made  up  of  parts  such  as  chapters,  sections,  tables,  page  headers,  and 
footers,  etc.  Many  memos  in  an  office  have  a  common  logical  structure.  Another 
example  is  a  ietter,  which  irtciudes  a  date,  a  return  address,  a  salutation,  a  body,  and  a 
dosing.  Each  of  these  “parts”  is  a  part  of  the  logical  structure  of  the  document 

The  layout  structure  of  a  document  defines  the  areas  of  interest  on  a  page  which  are  to 
be  filled  with  specific  types  of  content  or  data.  Many  pages  of  a  report  can  have  the 
same  layout,  with  areas  for  a  header  or  footer,  b(^  text  footnotes,  etc.  For  the 
example  of  a  ietter,  there  is  a  layout  structure,  as  well  as  a  logical  structure,  for  the 
return  address,  the  salutation,  the  body,  and  the  dosing;  this  indudes  the  location  on 
the  page,  the  font,  the  margins,  etc. 

ODA  also  defines  several  content  architectures.  The  content  architectures  are  the 
descriptions  of  the  actual  information  in  a  document  (the  information  that  is  placed  into 
the  layout  areas).  Currently  there  are  three  content  architectures  defined:  characters 
(text),  raster  graphics  (CCITT  Group  3  or  Group  4  facsimile  image  encoding),  and 
geometric  graphics  (Computer  Graphics  Metafile  -  CGM).  Our  e>  'jnple  of  a  letter  might 
indude  text  content 

The  Open  Document  Architecture  (OD/^  standard  (ISO  8613)  is  not  a  CALS  standard 
or  specification.  It  is  however  referenced  by  the  CALS  raster  specification  MIL'R- 
28002B. 

11.1.2  Encodings 

There  are  two  ways  to  encode  the  format  and  contents  of  an  ODA  conforming 
document  If  the  Abstract  Syntax  Notation  One  (ASN.1)  is  used,  the  resulting  form  is 
called  ODIF.  If  the  Standard  Generalized  Markup  Language  (SGML^  is  used,  the 
resulting  form  is  called  ODL,  aiid  the  result  is  an  SGML  application  conforming  to  ISO 
8879  (SGML).  In  this  case,  the  SGML  language  is  used  as  an  “envelope*  for  the  ODA 
document 
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11.1.3  Production  Support 

An  OOA  document  will  be  able  to  use  typographic  fonts  defined  by  the  Forrt 
Architecture  standard  currently  being  developed  by  the  Accredited  Standards 
Committee  X3V1  (the  US  OOA  TAG).  Typographic  fonts  are  essential  for  production  of 
high  quality  annotated  graphic  pictures. 

Color  can  be  specified  using  the  capabilities  of  the  OOA  color  addendum  recently 
approved  by  ANSI.  This  addendum  provides  for  several  different  color  spaces  to  be 
defined,  and  permits  calibration  data  for  the  primaries  and  wfste  point  to  accompany 
content  data,  so  that  color  correction  can  be  performed.  However,  since  the  document 
may  be  produced  on  a  monochrome  workstation,  or  printed  on  a  black  and  white 
printer,  the  direct  specification  of  color  may  be  meaningless  in  the  final  output 

ODA  can  be  translated  into  SPDL  (Standard  Page  Description  Language),  which 
provides  efficient  mapping  and  output  of  OOA  documents  as  well  as  other  documents,- 
to  intelligent  printers  for  execution. 

11.2  TYPICAL  APPUCATIONS 

Examples  of  applications  where  ODA  may  be  considered  include: 

•  Small  office  documents  (i.e.,  letters,  memos,  reports,  contracts,  invoices) 

•  Documents  where  the  exact  format  must  be  carefully  preserved  during 
interchange 

•  Documents  with  a  short  life  cycle  (i.e.,  littie  update  and  maintenance  is  required) 

•  Documents  that  will  not  include  portions  that  need  to  be  reused  to  create  other 
products 

•  Documents  that  are  not  required  to  support  concurrent  engineering  (i.e., 
inteiiigent  hooks  into  database  information). 

11.3  ARCHITECTURE 
11.3.1  ODA  Architecture 

The  ODA  standard  uses  the  term  "architecture*  to  describe  its  capability  to  define  the 
structure  of  documents  made  up  of  numerous  "infomiation  objects.*  Often  these 
documents  are  "compound*  in  that  they  contsun  different  types  of  data  (content 
architectures).  This  use  of  the  term  "architecture*  is  significant  in  comparison  to  the 
SGML  standard,  where  there  is  no  "architecture*  in  the  standard.  The  SGML  elements 
and  their  accompanying  semantics  are  manipulated  by  a  set  of  rules  (a  syntax  for 
creating  an  architecture). 
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1 1 .3.2  Architectur*  of  the  Standard 


The  OOA  Standard  does  not  define  a  data  format  which  has  to  be  used  by  an  OOA 
implementation  for  the  internal  storage  of  documents.  It  also  does  not  define 
functionality  for  preparing,  deleting,  filing,  or  retrieving  documents.  CiaTentiy  there  are 
seven  parts  to  the  ODA  standard: 

•  Part  1:  Introduction  and  General  Prindptes  -  contains  an  overview  of  the 
complete  standard,  including  descriptions  of  the  other  parts  as  well  as  their 
interdependencies.  An  annex  shows  the  relationsNp  of  ODA  to  other 
standards,  such  as  transfer  standards  and  SGML 

•  Part  2:  Document  structures  -  specifies  the  gerwrai  stixictural  concepts  for  ODA 
documents.  This  part  defines  the  basic  elements  of  a  document  architecture 
and  the  conceptual  models  necessary  to  understand  the  layout  and  imaging 
processes.  It  also  defines  the  classes  of  allowed  document  architectures. 

•  Part  4:  Document  profile  •  describes  the  purpose  and  attributes  of  a  document 
profile  (i.e.,  a  separate  constituent  of  a  document  consisting  of  a  set  of 
attributes). 

•  Part  5:  Office  document  interchange  format  (ODIF)  >  defines  the  precise  rules 
for  the  data  stream  of  an  interchanged  document  ODIF  is  based  on  the 
Abstract  Syntax  Notation  One  (ASN.1)  defined  in  ISO  8824:  1987,  Information 
Processing  Systems  •  Open  Sy^ems  Interconnection  -  Specification  of  Abstract 
Syntax  Notation  One  (ASN.1)  and  tSO  8825;  1987,  Information  Processing 
Systems  •  Open  Systems  Interconnection  •  Specification  of  Basic  Encoding 
Rules  for  Abstract  Syntax  Notation  One  (ASN.1).  This  part  also  defines  a  dear 
text  encoding  called  Open  Document  Language  (ODI4  which  is  based  on  ISO 
8879:  1986,  Information  processing  •  Text  and  Office  Systems  •  Standard 
Generalized  Markup  Language  (SGML).  ISO  9069:  1988,  Information 
processing  -  SGML  support  fadiities  -  SGML  Document  Interchange  Format 
(SDIF)  defines  the  interchange  of  ODA  documents  encoded  using  ODL 

•  Part  6:  Character  content  architectures  •  defines  the  encoding,  the  attributes, 
and  the  implementation  of  the  layout  and  imaging  processes  for  character 
content  (text)  in  ODA  documents.  The  attributes  include;  direction;  spadng,  and 
subscript/superscript;  font,  ims^e  inversion  (the  exchange  of  color  between  the 
graphic  symbol  and  the  character  box);  crossing  out  (deletions);  blinking; 
underlining;  style  (italics);  tabular  attributes;  Indentation  rules  and  interactions 
between  presentation  attributes  and  layout  directives;  and  control  functions, 
such  as  carriage  return,  tabs,  line  feed. 
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•  Part  7:  Raster  graphics  content  architecture  •  defines  the  encoding,  the 
attributes  and  the  implementation  of  the  layout  and  imaging  processes  for  raster 
graphics  data.  At  present  this  part  does  not  support  grayscale  or  multi-coloured 
pictures. 

•  Part  7:  Tiling  Addendum  •  contains  the  extensions  to  Part  7  needed  to 
implementing  tiling.  Such  attributes  as  tile  size  and  tile  type  are  specified. 

•  Part  7:  Additional  Bit  Order  Mapping  Addendum  -  contains  the  extensions  to 
Part  7  needed  to  encode  CCITT  Recommendation  T.4/T.6  data  in  the  down  bit 
order  sequence. 

•  Part  8;  Geometric  graphics  content  architecture  •  defines  the  encoding,  the 
attributes,  and  the  implementation  of  the  layout  and  imaging  processes  for 
these  pictures.  The  model  for  geometric  graphics  is  ISO  8632  Computer 
Graphics  Metafile  for  the  Storage  and  Transfer  of  Picture  Description 
Information  (CGM).  An  ODA  geometric  picture  is  a  picture  encoded  as 
Computer  Graphics  Metafile,  in  which  the  rules  for  determining  the  default 
values  of  CGM  parameters  and  the  coordinate  system  are  different  than  those 
in  ISO  8632.  In  addition,  in  ODA  a  CGM  may  contain  only  one  picture. 

•  Part  9:  (to-be-published)  -  will  describe  the  audio  content  architecture. 

•  Part  10:  Formal  specifications  -  describes  a  Formal  Description  Technique 
(FDT)  with  precise  and  unambiguous  syntax  and  semarttics  based  on 
mathematical  means/methodoiogy.  The  aims  of  the  Formal  Specifications  of  the 
ODA  Standard  (FODA)  are  to  provide:  a  basis  for  implementations  of  the 
Standard;  a  tool  for  the  verification  of  corrforming  system;  and,  a  reference  point 
for  future  extensions  and  revisions  to  the  Standard.  This  part  currently  only 
contains  an  FDT  for  document  structures  defined  in  Part  2,  but  the  development 
of  FTDs  for  the  different  content  architectures  contained  in  other  parts  of  the 
Standard  are  underway. 


1 1 .4  INTERNATIONAL  STANDARD  PRORLES 

International  Standard  Profiles  (ISPs)  are  made  of  three  parts:  a  Document  Application 
Profile,  Implementation  Support  Requirements  (iSR)  and  Abstract  Test  Cases  (ATC). 
Proposed  Draft  International  Standardized  Profiles  (pDiSP)  need  only  contain  Part  1 ,  a 
DAP,  to  be  considered  by  international  standards  bodies.  ODA  DAPs  describe 
restricted  subsets  of  the  wide  range  of  objects  available  under  the  ODA  base 
international  standard.  DAPs  are  a  way  of  standardizing  the  logical  attributes  of  a  class 
of  applications,  with  the  result  being  that  standard  features  used  by  a  sender  are 
processable  by  a  receiver.  DAPs  relieve  implementors  of  having  to  support  features  not 
of  use  to  a  particular  application.  If  a  pDISP  is  considered  to  have  the  potential  to 
become  an  international  Profile,  it  becomes  an  Open  Document  Format  (FOD). 
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Implementation  Support  Requirements  (ISR)  define  the  features  of  the  DAP  that  must 
be  supported  by  both  a  generator  of  a  DAP  compliant  ODA-document  and  the  receiver 
of  the  ODA-document  This  implementation  of  the  DAP  may  designate  which  options  in 
the  DAP  are  used  and  may  not  utilize  the  features  of  the  DAP.  An  ISR  may  e)ust  for 
a  region,  country  or  group  of  countries.  And  therefore  a  DAP  may  have  several  ISRs. 
ISRs  are  used  as  a  part  of  contracts  to  designate  generator  and  receiver  requirements. 

Abstract  Test  Cases  or  Suites  contain  DAP  implementation  results  that  may  be  used  to 
test  generator  or  receiver  compliance  to  the  DAP. 

1 1 .5  STATUS  AND  PLANNED  EXTENSIONS 

ISO  8613  ODA  was  first  published  in  1989  and  was  intended  originally  for  office 
documents  such  as  page-oriented  memos,  reports,  letters,  invoices,  etc.  Since  its 
publication  several  modifications  and  extensions  have  been  made  a  part  of  the 
standard.  It  should  be  kept  in  mind  that  all  changes  to  ISO  8613  are  also  reflected  in 
the  CCtTT  T.410  series  of  Recommendations  and  visa  versa.  The  Consultative 
Committee  on  Telegraph  and  Telephone  (CCITT)  has  recently  changed  Its  name  to 
Telecommunication  Standards  Sector  (TSS)  and  so  all  new  or  revised 
recommendations  will  bare  this  new  name. 

The  CALS  standard  for  interchange  of  raster  data,  MIL-R-28002  (Type  I  and  Type  II  as 
defined  in  NISTIR  68-4017)  was  first  issued  in  December  1988.  It  was  revised  by 
MIL-R-28002A  in  November  of  1990  and  again  by  MiL-R-28002B,  14  December  1992. 
The  MIL-R-28002  (Raster)  specification  establishes  requirements  for  a  standard 
interchange  file  format  and  raster  encoding  scheme  for  raster  data.  MiL-R-28002  Type 
11  data  is  a  MIL-STD-1640  header  wrapped  around  an  Open  Document  Architecture 
(OOA)-style  document  conforming  to  the  Document  Application  Profile  (DAP)  for  raster 
contained  In  Part  7. 

Although  the  addendum  to  Part  7  can  be  obtained  from  the  CCITT  or  ISO  editors,  these 
documents  have  not  been  formally  published  by  ISO.  A  new  version  of  ISO  6613  (ODA) 
was  originally  expected  in  1992,  so  it  was  determined  that  the  addenda  would  simply 
be  released  as  a  part  of  this  new  version.  The  publication  of  this  new  version  is  now 
expected  sometime  in  1993,  and  these  addenda  have  yet  to  be  formally  released. 
Telecommunication  Standards  Sector  (TSS),  formerly  CCriT.  has  released 
"Recommendation  T.417:  Information  Technology  -  Open  Document  Architecture 
(ODA)  and  Interchange  Formats  -  Raster  Graphics  Conterrt  Architectures*  which  will 
become  ISO  8613  (ODA)  Part  7.  TSS  Recommendation  T.417  does  contain  these 
required  addenda 

The  following  addenda  are  extensions  to  ISO  8613: 

•  Addendum  on  document  application  profile  proforma  and  notation 
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•  Addendum  on  styles 

•  Addendum  on  alternate  representations 

•  Addertdum  on  security 

•  Addendum  on  tiled  raster  graphics 

•  Adderxlum  on  color  and  grayscale 

Extensions  currerrtly  being  considered  by  ISO  and  TSS  are; 

•  Limited  hypermedia  extensions 

•  The  reiatiortship  of  ODA  to  voice  messaging 

•  Distributed  applications 

•  Simultaneous  access  to  a  document 

•  The  definition  of  office  procedures 

•  Human  interf^  to  ODA  documents 

•  Cooperative  work  on  documents 

•  incorporation  of  material  by  external  reference 

•  Staictures  without  a  defined  relationship  to  ODA 

•  Temporal  relationships 

•  Embedded  annotations  and  attached  annotations 

•  Formulas  and  expressions 

•  Tables  and  spread  sheets. 

1 1 .6  ADVANTAGES  OF  CURRENT  SPECIFICATION 

The  ODA  standard  allows  the  storage  of  complex  documents  containing  graphics  and 
textual  informabon  and  the  production  of  compound  documents  using  facsimile 
technology.  ODA  gives  authors  the  option  of  full  control  over  the  appearance  of  their 
documents.  In  many  situations  this  control  is  a  business  requirement  An  architecture 
is  predefined  within  the  ODA  standard,  assuring  its  ability  to  be  interchanged  in  an 
open  environment  without  the  need  for  negotiation  between  originator  and  receiver. 

1 1 .7  IMPLEMENTATION  ISSUES 

ODA  puts  focus  on  the  layout  of  a  document  not  its  iogicai  structure.  For  this  reason, 
an  ODA-formatted  document  loses  the  identity  of  titles,  footnotes,  etc.;  they  are  all 
character  strings.  The  content,  then,  of  the  document  has  been  lost  to  an  intelligent 
automatic  recipient.  As  ttie  CALS  environment  moves  towards  integrated  databases 
and  shared  ds^  ODA  may  not  sufficiently  handle  future  requirements. 

in  addition,  the  relative  iack  of  intelligence  and  pointers  to  the  information  may  inhibit 
the  ability  of  ODA  to  develop  adequate  extensions  for  hypertext  and  hypermerfia, 
where  intelligent  data  is  a  requirement  This  deficiency  inhibits  ODA's  abUity  to  support 
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automated  processing  such  as  an  intelligent  Electronic  Review  process  in  which 
comments  can  be  associated  with  the  information  objects. 

In  OOA.  the  architecture  and  the  semantics  are  defir>ed  within  the  standard.  This 
restricts  the  capability  of  ODA  to  support  new  applications  for  new  functional  areas. 
This  is  a  problem  with  including  an  ODA  application  in  RPS  PllB  146-1  Government 
Open  Systems  Interconnection  Profile  (GOSIP),  since  it  means  that  many  applications 
must  be  included,  one  for  each  specific  type  of  document 

The  initial  surge  of  CALS  attention  given  to  SGML  has  raised  the  issue  of  just  how 
SGML  and  ODA  can  live  together  in  the  same  system,  or  if  they  should  Most  experts 
on  the  sut^ect  agree  that  ODA  can  be  embedded  into  SGML,  through  ODL  EWOS/EG 
ODA/PT  N  01 1  SGML/ODA  Convergence  is  a  report  that  discusses  OOA  and  SGML 
interrelationships  and  is  the  result  of  the  European  Workshop  for  Open  Systems 
(EWOS).  The  differences  in  targeted  users  (ODA  is  strictiy  for  business  applications; 
SGML  is  more  general  purpose)  has  been  a  common  distinction,  but  is  biuning  as  the 
ODA  community  attempt  to  gain  ground  by  showing  that  documents  other  than  'office* 
documents  can  be  transferred  with  ODA.  However,  the  strong  tie  between  OOA 
objects  and  format  presents  a  serious  obstacle  to  OOA  becoming  a  useful  neutral  data 
forimat  appropriate  for  reuse. 

There  is  concern  within  the  computer  graphics  standards  community  about  Part  8  of  the 
OOA  standard.  Although  this  part  defines  an  ODA  CGM  Application  Profile,  the  CGM 
committees  (ANSI  X3H3  and  ISO  SC24)  consider  It  of  such  poor  quality  that  good 
implementations  might  not  meet  ft  and  bad  implementations  could  while  providing  no 
dependable  communication  of  the  picture.  One  example  of  a  mistake  In  this  CGM 
application  profile  is  that  It  does  not  require  the  spe^cation  of  a  font  list.  This 
guarantees  uncertainty  of  the  final  outcome  from  any  transfer  of  the  CGM. 

Although  ODA  proponents  want  ODL  encoding  of  ODA  for  CALS,  other  CALS  users 
declare  that  CALS  documents  cannot  be  generated  in  ODA  (the  redundant  storage  of 
data  inherent  in  the  ODA  combination  of  formatting  and  content  does  not  neatly  fit  with 
some  of  the  CALS  goals).  The  presence  of  ODA  in  GOSIP  as  an  exchange  format 
suggests,  to  some  users  and  implementers,  that  no  other  document  exchange  standard 
may  be  used  by  the  Government  and  that  ODA  is  the  only  format  that  can  be 
exchanged  through  the  GOSIP  environment.  Pag  10  of  RPS  PUB  146-1  (GOSIP) 
states  the  following  "  Although  ODA  is  not  an  ISO  protocol.  It  is  included  in  GOSIP 
because  It  provides  services  required  by  Federal  agencies,  and  Informafion  specified 
by  the  standard  can  be  transported  by  the  OSI  FTAM  and  MHS  Application  layer 
protocols.*  Section  4.2.8. 1  Office  Document  Architecture  (OD/^  describes  the  transfer 
of  an  ODA  via  services  provided  by  MHS  or  FTAM.  Neither  reference  indicates  that 
ODA  is  the  only  exchange  format  that  can  be  used  for  documents. 
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1 1 .8  EXTENT  AND  NATURE  OF  USER  AND  VENDOR  SUPPORT 


The  National  Institute  of  Standards  and  Technology  (NIST)  has  formed  an  OSI 
Implementors  Workshop  ODA  Special  Interest  Group.  This  group  is  made  up  of  large 
end-users  and  computer  vendors,  DoD  and  NIST  participarTts  and  is  responsible  for 
identifying  agreed  upon  standards  for  the  OSI  environment  The  scope  of  the  ODA  SIG 
is  to  develop  agreements  concerning  implementation  and  testing  of  ODA  systems 
based  on  ISO  8613,  its  addendum  and  related  international  standards.  It  was 
responsible  for  developing: 

•  ISO/IEC  International  Standard  Profile  (ISP)  11181-1:  1992,  information 
technology  -  Standardized  Profile  FOD26  -  Office  Document  Format:  Enhanced 
document  structure  -Ch7/acter,  raster  graphics  and  geometric  graphics  content 
architectures  -  Documer.t  Application  Profile. 

•  ISO/IEC  Intematioi^  Standard  Profile  (ISP)  11182-1:  1992,  Information 
technology  -  Standardized  Profile  F0036  -  Office  Document  Format:  Enhanced 
document  structure  -  Character,  raster  graphics  and  geometric  content 
architectures  -  Document  Application  Profile. 

•  Stable  Implementation  Agreements  for  Open  Systems  Interconnection 
Protocols:  Part  22  -  ODA  Image  DAP,  March  1993;  and 

•  Stable  implementation  Agreements  for  Open  Systems  Interconnection 
Protocols:  Part  23  -  ODA  Raster  DAP,  March  1993. 

NIST  is  planning  to  issue  the  ODA  Raster  DAP  as  a  RPS  PUB  by  the  end  of  1993. 
Once  the  FIPS  is  in  place  MIL-R-28002  vtrill  no  longer  contain  the  ODA  Raster  DAP  as 
an  appendix,  and  in  its  place  will  reference  the  appropriate  RPS.  NIST  has  also  added 
ODA  into  their  Application  Portability  Profile. 

The  ODA  Raster  DAP  published  in  the  September  1992  OIW  Stable  Implementation 
Agreements  and  Appendix  A  to  MIL-R-28002B,  was  presented  to  the  Profile  Alignment 
Group  for  ODA  (PAGODA)  for  consideration  as  an  International  Profile.  PAGODA 
delegations  agreed  to  propose  to  the  respective  workshops  that  a  specification  be 
developed  with  the  intent  of  achieving  a  proposed  Draft  Intemationai  Standardized 
Profile  (pDISP).  In  Intemationai  circles  a  Profile  is  called  an  Open  Document  Format 
(FOD).  The  ODA  Raster  DAP  was  widely  circulated  among  the  respective  workshops 
and  comments  were  fonArarded  to  the  OIW  ODA  SIG.  PAGODA  delegations  represent 
the  OIW,  Asia-Oceania  Workshop  (AOW),  European  Workshop  for  Open  Systems 
(EWOS),  and  CCITT  Study  Group  VIII.  PAGODA  has  requested  that  FOD1 12  allow  the 
512  tile  size  default  and  any  other  tile  size  for  greater  flexibility.  This  tile  size  change 
was  made  to  FOD1 12,  but  not  to  the  ODA  Raster  DAP.  Therefore  the  ODA  Raster  DAP 
is  now  a  subset  of  pDISP  FOD1 12.  This  profile  vrill  be  reviewed  using  the  Intemationai 
Profile  Progressive  Schedule  with  a  June  1994  projected  date  for  becoming  an 
Intemationai  Profile. 
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The  Electronic  Imaging/Compression  Committee  (C.13.7)  of  the  Association  for 
information  and  Image  Management  (AlIM)  has  developed  a  standard.  ANSI/AIIM 
MS53  1993,  "Standard  Recommended  Practice  •  RIe  Format  for  Storage  and 
Exchange  of  images  •  Bi-Level  image  Rie  Format  Part  1",  that  specifies  a  file  format 
for  the  exchange  of  bi-level,  electronic  images.  MS53  is  considered  a  subset  of  the 
ODA  Raster  DAP,  but  it  does  not  allow  for  the  tiling  of  raster  images.  This  standard  has 
been  developed  to  encourage  the  use  of  ODA  by  the  United  States  image  technology 
commurtity  and  to  provide  a  much  needed  standard  bi-level  image  file  formal  it  is  seen 
as  an  introductory  tool  for  users  and  implementors  of  ODA  ASN.1  and  ODA  Raster 
DAP  applications  requiring  MiL-R-28002  Type  II  untiled  data  MS53  is  AIIM's  attempt  at 
a  "cookbook*  approach  to  the  exchange  of  bi-level  electror^c  images  using  ODA  with 
ASN.1  encoding. 

Several  of  the  document  systems  that  produce  or  accept  either  an  ODA  ODIF  or  an 
ODA  ODL  data  stream  are: 

•  InterUnear 

•  Digital  Equipment  Corporation  (DEC):  Compound  Document  Architecture  with 
ODA-iike  features  which  supports  ODIF. 

•  International  Business  Machines  (IBM):  ODA-based  product 

•  Nixdorf  of  Canada*  ODA-based  product  that  creates  an  ODIF  output 

•  Several  companies  in  Europe. 

•  The  European  Economic  Community  ESPRIT  project 

1 1 .9  STRUCTURE  OF  DEVELOPMENT  ORGANIZATION 

The  ODA  standard  was  developed  within  ANSI  Accredited  Standards  Committee  X3V1 
Text  and  Office  Systems.  Its  international  counterpart  (ISO  8613)  was  developed  by 
ISO  SCI 8  Working  Group  3. 

1 1 .1 0  REFERENCE  AND  IMPLEMENTATION  DOCUMENTS  AVAILABLE 

1.  Appelt  Wolfgang.  Document  Architecture  in  Open  Systems,  The  ODA 
Standard,  Springer- Verlag,  New  York,  1991. 

2.  ANSI/AIIM  MS53-1993:  Standard  Recommended  Practice  -  Rie  Formal  for 
Storage  and  Exchange  of  Images  -  Bi-Level  image  File  Format:  Part  1. 

3.  CCnr  Recommendation  T.6:  1988,  Facsimile  Coding  Schemes  and  Coding 
Corrtrol  Functions  for  Group  4  Facsimile  Apparatus. 
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4.  FIPS  PUB  150:  4  November  1988,  Telecommunications:  Facsimile  Coding 
Schemes  and  Coding  Control  Functions  for  Group  4  Facsimile  Apparatus. 

5.  ISO  8613-1:  1989,  Information  processing  -  Text  and  Office  Systems;  Open 
Document  Architecture  (OOA)  and  Interchange  Format  -  Part  1:  Introduction  and 
General  Phndpies. 

6.  ISO  8613-2:  1989,  Information  processing  -  Text  and  Office  Systems;  Open 
Document  Architecture  (ODA)  and  interchange  Format  •  Part  2:  Document 
Structure. 

7.  ISO  8613-5:  1989,  Information  processing  -  text  and  Office  Systems;  Open 
Document  Architecture  (OD/^  and  Interchange  Format  -  Part  5:  Open 
Document  Interchange  Format 

8.  ISO  8613-7:  (to  be  published  in  1993),  information  processing  -  Text  and  Office 
Systems;  Open  Document  Architecture  (ODA)  and  Interchange  Format  -  Part  7; 
Amendment  -  Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 

9.  ISO  8613-7:  (to  be  published).  Information  processing  -  Text  and  Office 
Systems;  Open  Document  Architecture  (OD^  and  Interchange  Format  -  Part  7; 
Amendment  •  Additional  Bit  Order  Mapping  Addendum  to  ISO  8613,  Ffort  7. 

10.  ISO  8824:  1987,  Information  Processing  Systems  •  Open  Systems 

Interconnection  •  Specification  of  Abstract  Syntax  Notation  One  (ASN.1). 

11.  ISO  8825:  1987,  Information  Processing  Systems  -  Open  Systems 

Interconnection  -  Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax 
Notation  One  (ASN.1). 

12.  ISO  8879:  1986,  Information  processing  -  Text  and  Office  Systems  -  Standard 
Generalized  Markup  Language  (SGML). 

13.  ISO  9069:  1988,  Information  processing  -  SGML  support  facilities  -  SGML 
Document  Interchange  Format  (SDIF). 

14.  MIL-M-28001:  1990,  MILITARY  SPECIFICATION,  MARKUP  REQUIREMENTS 
AND  GENERIC  STYLE  SPECIFICATIONS  FOR  ELECTRONIC  PRINTED 
OUTPUT  AND  EXCHANGE  OF  TEXT. 

15.  "User  Requirements  for  the  New  Project  on  'ODA  Document  Processing’," 
X3V1. 1/90-44. 

16.  "Standards  for  the  Interchange  of  Large  Format  Tiled  Raster  Documents," 
NISTIR  88-4017. 

17.  CALS  Report,  Vol  2,  No.  8,  August  1989. 


11  -  10 


18.  "Overview  of  X3V1  (Text  and  Office  Publishing  Systems)  Standards,"  B. 
Shepherd,  X3H3/89'167. 

19.  "ODA;  What  Is  It?  What  Is  It  Good  For?,*  The  Seybold  Report  on  Publishing 
Systems,  Volume  19,  Number  7. 

20.  Kemmerer,  S.J..  October  1992,  Computer-aided  Acquisition  arxi  Logistic 
Support  (CALS)  Testing;  Programs,  Status,  and  Strategy,  NISTIR  4940, 
Information  Sy^ems  Engineering  Division,  Computer  Systems  Laboratory, 
NIST. 

21.  Spieiman,  F.E  May  1992,  Raster  Graphics  Validation,  NISTIR  4848,  U.S. 
Department  of  Commerce,  Technology  Administration,  NIST. 

22.  Spieiman,  F.E,  and  Sharpe  LH.  1993,  Raster  Graphics:  A  Tutorial  and 
Implementation  Guide,  NISTIR  5108,  Computer  Systems  Laboratory,  NIST. 

23.  TSS  (formerly  CCITT)  Recommendation  T.417;  1993,  Infomiation  Technology  - 
Open  Document  Architecture  (ODA)  and  Interchange  Formats  -  Raster  Graphics 
Content  Architectures. 


11  -  11 


SECTION  12 .  IS0 10303  Stindante;  STEP/PDES 
12.1  Purpose: 

STEP  (STandard  for  the  Exchange  of  Product  model  data)  is  the  unofficial  name  for  the 
ISO  10303  standards  which  are  being  developed  by  the  International  Organization  for 
Standardization  (ISO).  STEP  is  formally  called  the  ‘industrial  Automation  Systems  and 
Integration  •  Product  Data  Representation  and  Exchange  Standard*.  In  the  Urtited 
States,  STEP  is  krK>wn  as  PDES  wNch  stands  for  'Product  Data  Exchange  using 
STEP*.  PDES  is  the  U.  S.  organizational  activity  that  supports  the  development  and 
implementation  of  STEP. 

STEP  is  an  international  standard  wNch  is  being  designed  to  give  a  complete 
computer-interpretable  representation  of  product  data  in  a  neutral  format  throughout 
the  complete  product  Hfe-cyde  (design,  engineering  analysis,  manufacture,  support  and 
maintenance,  and  disposaQ.  TMs  representation  makes  it  suitable  not  only  for  file 
exchange  but  also  as  a  basis  for  inftpiementation,  sharing,  and  archiving  product 
databases. 

With  the  proliferation  of  computer-aided  design,  manufacturing,  and  engineering 
systems  (CAD/CAM/CAE),  all  product  data  can  be  captured  in  digital  form.  The  ability 
to  transfer  such  product  data  in  computer-readable  format  from  one  system  to  another 
is  essential.  Once  the  STEP  standwd  is  defined  and  implemented  on  various  systems, 
then  such  systems  can  accept,  use.  and  exchange  product  data  so  that  developers, 
suppliers,  vendors,  and  manufacturers  will  be  able  to  receive  and  supply  information 
about  product  parts  and  materials  digitaliy.  This  will  mean  shorter  development  times, 
higher  quality  products,  lower  costs.  It  will  also  ensure  flexibility  and  responsiveness  to 
the  needs  of  customers,  manufacturers,  suppliers,  and  users. 

The  STEP  standards  are  fundamental  to  the  Computer-aided  Acquisition  and  Logistics 
Support  (CALS)  effort  CALS  encompasses  an  architecture  for  Contractor  Integrated 
Technical  Information  Services  (Cm^  which  requires  an  Integrated  Weapon  System 
DataBase  (IWSDB).  The  STEP  shared  data  environment  will  provide  the  kernel  of  the 
IWSDB  and  will  support  information  access  for  prime  contractors,  sub-contractors,  and 
the  DoD. 

The  scope  of  STEP  standards  development  is  immense  with  respect  to  the  variety  of 
products  addressed.  It  is  important  to  the  United  States'  competitive  posture  in  the 
world  marketplace  that  the  STEP  worldng  experience  base  be  strengthened  through 
increased  American  participation  so  that  the  STEP  standards  will  favorably  encompass 
American  industry  practices  and  requirements. 
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MJ2.  Typical  Application: 


A  typical  application  of  product  data  in  the  form  of  a  STEP  file  is  shown  in  the  following 
figure: 
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Rgure  3  >  Example  of  a  STEP  data  file 


12^  Architecture  of  the  Standard: 

12^.1  STEP  Parts: 

STEP  is  organized  as  a  series  of  Parts  which  are  divided  into  six  logical  groups.  Each 
of  these  groups  is  called  a  Class.  Each  Class  has  a  unique  function  in  STEP.  Within 
each  Class,  documentation  for  each  Part  is  being  developed.  STEP  is  being  pubfished 
as  a  set  of  inter-related  standards,  each  of  which  falls  into  one  of  the  six  Classes  in  the 
following  figure. 
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OVERVIEW  (Parts  1-9) 


Description 

Implementation 

Conformartce 

Methods 

Forms 

Testing 

(Parts  10  - 19) 

(Parts  20  -  29) 

(Parts  30  •  39) 

integrated 
Resources 
(Parts  40  - 199) 


Application 
Protocol 
(Parts  200  •<•) 


Rgure  4  •  STEP  Parts 


12^.1.1  Overview  (Parts  1  -  9): 

This  Class  provides  an  overview  of  all  the  STEP  standards.  Currently,  only  one  Part, 
Part  1  •  Overview  and  Fundamental  Principles,  has  been  developed.  Other  Parts  in 
this  Class  may  be  developed  in  the  future. 

12^.1^  Description  Methods  (Parts  10  •  19); 

This  Class  specifies  the  methods  used  to  describe  the  information  models  found  in  both 
the  Integrated  Resources  Class  and  Application  Protocols  (APs)  Class.  Only  one  part. 
Part  11  •  EXPRESS  language,  has  been  developed. 

The  EXPRESS  language  provides  the  mechanism  for  the  description  of  product  data 
for  both  integrated  resources  and  APr  within  STEP.  This  description  is  independent  of 
any  implementation  method  and  will  support  all  such  methods  defined  in  STEP 
consistently. 
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12.3.1.3  Implementation  Forms  (Parts  20  •  29): 

This  Class  specifies  the  methods  for  exchanging  and  sharing  data  captured  from 
information  models.  Only  Part  21  which  defines  the  passive  file  exchange 
implementation  method  has  been  developed. 

12.3.1.4  Conformance  Testing  (Parts  30  -  30): 

This  Class  specifies  the  methods  that  determine  whether  a  STEP  implementation 
conforms  to  the  standard.  Only  Part  31  dealing  with  Conformance  Testing 
Methodology  has  been  developed. 

12.3.1.5  Integrated  Resources  (Parts  40  - 199): 

This  Class  provides  the  specification  of  integrated  conceptual  information  models  for  all 
of  the  STEP  effort  Within  this  Class,  there  are  two  types  of  STEP  Parts: 

a  Generic  Resources  (Parts  40  •  99):  These  are  Parts  comprised  of  concepts  and 
constructs  that  may  be  used  by  many  applications,  including  the  higher  level 
Application  Resources  and  APs. 

b.  Application  Resources  (Parts  100  - 199):  These  are  Parts  containing  conceptual 
constructs  for  specific  application  areas.  These  Parts  may  be  used  by  many 
APs. 

12.3.1.6  Application  Protocols  (Parts  200  •«■): 

These  Parts,  the  Application  Protocols  (APs),  provide  the  mechanism  both  for 
specifying  implementation  requirements  and  for  ensuring  reliable  information 
communication  within  the  context  of  a  given  applicatioa  An  AP  is  a  complete 
specificafion  of  the  context  and  scope  for  the  use  of  product  data  in  a  particular  domain 
using  standardized  integrated  resources  and  other  application  specific  entities.  The  AP 
also  describes  the  conformance  requirements  and  test  purposes  from  which  its  abstract 
test  suite  is  derived.  Parts  in  this  Class  are  numbered  200  and  above.  (See  Section 
12.4) 


12.3.2  The  Component  of  STEP  AP: 

The  use  of  the  STEP  standards  to  support  a  particular  appficafion  domain  is  based  on 
the  concept  of  the  AP.  The  AP  provides  a  complete  explicit  statement  of  the  product 
data  representation  required  to  meet  the  specific  needs  of  a  particular  application.  The 
AP  defines  the  scope  and  context  of  the  application  in  terms  of  four  major  components: 

12.3.2.1  Scope  and  Application  Activity  Model: 

The  scope  statement  defines  the  domain  of  the  AP  and  summarizes  the  functionality 
and  data  that  are  accommodated  by  the  AP.  The  scope  statement  is  based  on  an 


12-4 


Application  Activity  Model  (AAM)  developed  by  the  Integrated  Computer-aided 
Manufacturing  Definition  Method  (IDEFO).  The  AAM  is  used  to  clarify  the  application 
activities,  processes,  and  data  flows  involved  in  the  application. 

12.3.2^  Information  Requirements  and  Application  Reference  Model: 

The  Application  Referertce  Model  (ARM),  formally  describes  the  information  content, 
structure,  and  cor^tralnts  with  regard  to  the  specific  application  domairt.  The  ARM 
provides  the  basis  for  specifying  and  verifying  the  information  requirements  of  the  AP. 
The  ARM  is  developed  in  one  of  the  following  modeling  languages;  EXPRESS,  the 
Integrated  Computer-aided  Marujfacturing  Definition  Method  (IDEF1X),  or  N^ssen's 
Information  Anal^s  Methodology  (NIAM). 

12.3.2.3  Application  Interpreted  Model: 

An  Application  Interpreted  Model  (AIM)  specifies  the  constructs  selected  from  the 
Integrated  resources  and  interprets  them  to  meet  the  needs  of  the  application.  The  AIM 
Is  defined  using  the  EXPRESS  language. 

12.3.2.4  Conformance  Requirements  and  Test  Purposes: 

The  AP  also  includes  a  set  of  conformance  requirements  artd  test  purposes  from  which 
an  abstract  test  suite  may  be  developed  and  used  for  conformance  testing. 

12.4  Status  and  Planned  Extensions: 

12.4.1  STEP  Initial  Release: 

Twelve  STEP  Parts  (Ref.  1)  were  registered  for  Draft  international  Standard  (DIS) 
status  in  May  1993.  This  initial  release  of  STEP  win  provide  capabilities  for  the 
exchange  of  two-dimensional  drafting  product  data  aixf  the  configuration  controlled 
exchange  of  three-dimensional  product  definition  data  with  emphasis  on  mechanical 
parts  and  assemblies.  The  initial  STEP  release  establishes  a  foundation  for  subsequent 
releases  of  STEP.  This  initial  release  of  STEP  includes  the  following  Parts; 

Part  1  -  Overview  and  Fundamental  Principles 

Part  1 1  -  EXPRESS  Language  Reference  Manual 

Part  21  -  Clear  Text  Encoding  of  the  Exchange  Structure 

Part  31  -  Conformance  Testing  Methodology 

Part  41  -  Fundamentals  Product  Description  and  Support 

Part  42  -  Geometric  and  Topological  Representation 

Part  43  -  Representation  Structures 

Part  44  -  Product  Structure  Configuration 

Part  46  -  Visual  Preserrtation 

Part  101  -  Drafting 

Part  201  -  Explicit  Drafting 

Part  203  -  Configuration  Controlled  Design 
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12.4J(  STEP  Subssquent  Releases: 

Subsequent  STEP  releases  will  provide  added  functionality  and  extend  the  capabilities 
of  the  Parts  in  the  Initial  Release.  The  schedule  for  these  STEP  subsequent  releases 
has  not  been  detmmined.  The  following  Parts  are  currently  being  developed. 

Part  22  •  STEP  Data  Access  Interface  (SDAI) 

Part  32-  Test  Laboratory  Requirements 

Part  33-  Structure  and  Use  of  Abstract  Test  Suites 

Part  34*  Abstract  Test  Methods 

Part  45*  Materials  Products 

Part  47-  Shape  Tolerances 

Part  48  -  Form  Features 

Part  104  -  Finite  Bement  Analysis 

Part  105  •  Kinematics 

Part  202  -  Associative  Drafting 

Part  204  -  Mechanical  Design  Using  Boundary  Representation 
Part  205  -  Mechanical  Design  Using  Surface  Representation 
Part  206  -  Mechanical  Design  Using  Wireframe  Representation 
Part  207  -  Sheet  Metal  Die  Planning  and  Design 
Part  208  •  Life  Cycle  Product  Change  Process 
Part  209  •  Design  Through  Analysis  of  Composite  &  Metallic  Structures 
Part  210  •  Electronic  Printed  Circuit  Assembly:  Design  and  Manufacture 
Part  21 1  •  Electronic  Printed  Circuit  Assembly:  Test.  Integrated  Diagnostics  and 
Remanufacture 

Part  212  -  Electrotechnical  Rants 

Part  213  -  NC  Process  Plans  for  Machined  Parts 

Part  214  •  Core  Data  for  Automotive  Mechanical  Design 

Part  215-  Ship  Arrangements 

Part  216  -  Ship  Molded  Forms 

Part  217  -  Ship  Piping  Systems 

Part  218  -  Ship  S^ctures 

Part  219  -  Dimensional  Inspection  Process  Planning 

1 2.5  Advantages  of  Current  Specification: 

STEP  is  an  extremely  broad  specification,  including  virtually  every  data  item  required  to 
develop,  analyze,  manufacture,  document,  and  support  products  ranging  from 
mechanical  products  to  electronic  products  to  large  structures  such  as  ships  and 
buildings,  etc. 

STEP  is  a  conceptual  specification  for  communicating  product  information  at  ail  stages 
in  a  product's  life  cycle,  covering  all  aspects  of  product  description  and  manufacturing 
specifications.  The  fundamental  componerrts  of  STEP  are  product  information  models 
and  specifications  to  exchange  information  corresponding  to  these  product  models. 

STEP  will  provide  tools  to  reduce  time  to  market,  reduce  costs,  improve  quality,  and 
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continuously  improve  processes.  STEP  will  allow  all  information  from  finance, 
marketing,  engineering,  manufacturing,  support,  etc.  to  work  together  and  share  Hata' 
STEP  data  is  open;  it  is  independent  of  the  applications  or  systems  that  create  it,  and  is 
accessible  to  and  usable  by  any  other  ap^ications  that  need  to  use  it.  STEP  will 
provide  the  ability  to  turn  data  into  meaningikjl  information  to  support  decision  making. 
STEP  will  provide  a  foundation  for  the  next  generation  of  open  systems. 

12.6  Implementation  Issues: 

The  initial  Release  or  OIS  STEP  is  available  for  implementation.  The  emphasis  on 
software  applications  is  currently  focused  on  creating  APs  which  are  focused  on  high 
value  industrial  processes. 

1 2.6.1  Implementation  of  APs: 

APs  are  the  implementable  parts  of  STEP.  Many  APs  are  in  the  planning  or 
development  sta^s.  Guidelines  (Ref.  2)  for  the  development  of  APs  are  documented 
and  are  available  through  the  U.  S.  Product  Data  Association  (see  Section  12.8.2). 

When  an  AP  is  proposed  for  development,  approval  is  required  from  the  IGES/PDES 
Organization  (IPO).  The  AP  proposal  requires  a  precise  definition  of  scope  and  a 
detailed  plan  for  development  The  development  of  the  AP  proceeds  in  accordarKe 
with  the  STEP  guidelirws.  The  draft  AP  is  reviewed  and  balloted  through  the 
international  standards  process. 

12.6.2  Software  Tools: 

There  is  a  growing  recognition  of  the  need  for  software  tools  to  facilitate  the  STEP 
standards  development,  application  software  implementation,  and  testing  process. 

Software  tools  can  be  catalogued  in  four  major  groupings. 

Standards  development  tools:  Parsers,  compilers,  editors,  schema  generators,  etc. 

STEP  data  exchange  tools;  Software  to  generate  and  interpret  STEP  physical  files  and 
databases,  etc. 

Data  management  tools:  STEP  data  access  interfaces  and  database  management 
software,  etc. 

End  User  Tools:  Translators,  etc. 

12.6.3  Implementation  Levels: 

STEP  provides  a  wide  variety  of  levels  for  system  implementation.  Implementation 
levels  are  particular  ways  of  storing,  exchanging  or  accessing  information  which  are 
distinguished  by  the  degree  of  data  sharing.  Those  levels  may  include  the  following: 
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•  Exchange  File  •  Product  data  is  exchanged  between  computer  systems  or 
applications  using  STEP  exchange  files  which  are  defined  in  STEP  Part  21. 
The  structure  of  the  exchange  file  is  derived  from  the  conceptual  data  moders 
EXPRESS  definition.  It  is  expected  that  the  early  use  of  STEP  will  involve  using 
exchange  files  to  move  data  between  systems. 

•  Database  >  Product  data  is  stored  artd  accessed  in  databases  based  on  various 
database  architectures  (such  as  relational  or  object-oriented).  This  database 
level  will  allow  application  developers  to  create,  martipulate,  and  share  STEP 
data,  based  on  standard  data  models  and  system  internes.  Applications  use  a 
standard  query  language  such  as  SQL  or  standard  interfaces  such  as  the  STEP 
Data  Access  Interface  (SDAI)  defined  in  Part  22. 

•  Data  Access  -  Product  data  can  be  accessed  independently  of  the  storage 
method  used. 

12.6.4  Testing: 

The  STEP  testing  activities  are  categori2ed  as  follows: 

•  Standards  testing:  It  addresses  the  quality  of  the  evolving  STEP  specification 
itself.  These  validation  efforts  provide  assurance  that  the  methods  employed  by 
STEP  will  indeed  work,  and  that  the  standard  provides  a  means  to  meet  the 
functionality  that  it  claims  to  support 

•  Component  testing:  This  is  the  preliminary  testing  conducted  by  the  STEP 
softvy^e  implementor  to  verify  that  the  application  software  addresses  both  the 
basic  requirements  imposed  for  compliance  with  the  standard  and  the  users' 
functionality  requirements. 

•  Conformance  testing:  It  evaluates  a  software  product  with  respect  to  the 
specifications  provided  in  a  Part  of  a  STEP  standard  and  tests  for  the  presence 
of  these  characteristics  required  by  the  standard  itself.  STEP  includes  the 
specifications  for  Conformance  testing  as  a  requirement  built  into  many  Parts  of 
the  standard. 

•  Acceptance  testing:  It  is  concerned  with  the  user's  specific  requirements.  It 
tests  a  software  product  against  a  set  of  requirements  defined  by  the  users  of 
that  software  product  This  type  of  testing  may  include  perft^ance,  user 
interfaces  and  inter-operability  with  other  systems. 

Current  efforts  are  primarily  focused  on  developing  methods  for  Conformance  and 
Standards  testing.  Component  and  Acceptance  testing  activities  have  just  gotten 
underway  within  the  vendor  and  user  communities. 
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12.6.5  Training  and  Education: 


The  STEP  standard  is  technically  complex  and  requires  different  types  of  skills  for  the 
from  development  of  the  standard,  as  well  as,  its  implementation  in  a  production 
environment  Training  has  been  focused  on  the  highly  technical  needs  of  the 
developers.  As  industry  proceeds  from  the  standards  development  stage  to  testing  and 
implementation,  additionai  types  of  training  are  needed  for  the  new  users,  new 
developers,  and  even  experienced  staff.  More  formal,  structured  trainirrg  programs  will 
be  required  to  effectively  transfer  the  needed  information  to  users. 

12.6.6  IGES  to  PDES  Migration: 

The  Initial  Graphics  Exchange  Specification  (IGES)  is  an  ANSI  standard  which  provides 
a  neutral  data  format  for  exchanging  mechartical  product  data.  IGES  was  not  originally 
irrtended  to  capture  extensive  product  information  for  the  entire  product  life-cycie. 
Strategies  for  migrating  from  IGES  to  PDES  are  being  proposed  by  and  discussed 
within  U.  S.  standards  development  bodies. 

12.7  Extent  and  Maturity  of  User  and  Vendor  Support 

Tools  for  modeling  and  developing  specialized  applications  in  STEP  have  been 
available,  primarfiy  in  standards  development  and  research  activities,  since  the 
mid-1980's.  As  the  technology  has  gauned  momentum,  commerdai  suppliers'  efforts 
are  being  focused  on  providing  more  toots  for  software  developers  and  implementors. 

Recent,  several  STEP  toolkits  have  been  introduced  commerdally.  These  tools 
provide  needed  resources  for  the  developers  and  implementors  and  they  should 
accelerate  development  of  applications.  There  is  a  growing  recognition  of  the  need  for 
software  tools  to  facilitate  development  and  testing  processes.  This  should  lead  to 
additional  tool  development  for  these  activities. 

1 2.8  Structure  of  Development  Organization: 

12.8.1  ISO  TC184/SC4: 

ISO  (Ref.  3)  was  established  in  1946  with  the  objective  of  promoting  the  worldwide 
development  of  standards  to  fadiitate  the  international  exchange  of  goods  and  services 
and  also  develop  coc^ration  in  the  sphere  of  intellectual,  scientific,  technological,  and 
economic  activity. 

In  1984,  ISO  initiated  Technical  Committee  TCI  84  (Industrial  Automation  Systems)  and 
formed  Subcommittee  SC4  (industrial  Data  and  Global  Manufacturing  Programming 
Language)  to  work  on  the  representation  and  exchange  of  digital  product  data.  The 
work  of  TC184/SC4  includes  development  of  international  standards  dealing  with  the 
use  of  digital  product  and  manufacturing  management  data.  The  TC184/SC4‘s 
technical  work  is  organized  into  eight  Working  Groups  (WGs)  and  three  Advisory 
Groups  (AGs). 
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WG2  •  Standards  Parts;  The  scope  of  WG2  is  to  design  a  set  of  standards  that  specify 
how  a  library  supplier  shall  describe  his  library  in  such  a  way  that  this  library  might  be 
integrated  automatically  into  any  User  Part  Library. 

WG3  •  Product  Modeling:  The  scope  of  WG3  is  to  develop  all  Parts  (resources  models 
and  application  protocols)  of  STEP  for  qualification  and  integration. 

WG4  •  Qualification  and  Integration;  The  scope  of  WG4  is  to  qualify  and  integrate  of 
all  Parts  of  STEP. 

WG5  •  Development  Methods;  The  scope  of  WG5  is  to  provide  the  methods  necessary 
for  the  development  of  STEP. 

WG6  •  Conformance  Testing;  The  scope  of  WG6  is  to  provide  standards  for  the 
conformance  testing  of  all  Parts  of  STEP. 

WG7  -  Implementation  Specifications;  The  scope  of  WG7  is  to  develop  the  physical  file 
standards  and  the  STEP  Data  Access  Interface  Specification,  and  also  to  serve  as  a 
resources  for  STEP  implementation. 

WG8  >  industrial  Manufacturing  Management  Data:  The  scope  of  WG8  is  to  develop 
the  methods  and  the  standardized  data  to  express  information  exchanged  inside 
industrial  manufacturing  plants. 

Strategic  Planning  Advisory  Group  (SPAG):  The  scope  of  SPAG  is  the  coordination  of 
SC4  activities. 

Project  Management  Advisory  Group  (PMAG):  The  scope  of  PMAG  is  the  project 
management  of  all  STEP  development  activities  within  SC4. 

Editing  Committee  (EC):  The  scope  of  EC  is  to  assist  in  the  preparation  of  texts, 
consistent  with  the  ISO  Directives  and  also  to  review  them  for  technical  coherence  with 
other  texts. 

12.8^  US  Product  Data  Association: 

US  PRO  is  the  parent  organization  that  provides  management  and  strategic  direction 
for  organizations  engaged  in  research,  development,  implementation,  and  testing  of 
standards  and  specifications  for  the  exchange  and  sharing  of  product  data  information. 
US  PRO  was  established  by  industry  to  work  on  its  behalf.  It  was  created  to  bring 
together  the  major  volunteer  user  communities  to  develop  standards,  and  also  to 
provide  a  forum  for  the  exchange  of  experiences.  Program  areas  include  the 
IGES/PDES  Organization  (IPO),  the  National  IGES  User  Group  (NlUG)  and  the  US 
Technical  Advisory  Group  to  ISO. 

IPO  was  established  in  1980  and  consists  of  over  500  voluntary  industry,  government. 
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and  academic  personnel  who  mbet  quarterly  to  work  on  technical  aspects  of  product 
data  exchange.  IPO  is  composed  of  two  groups,  the  Steering  Committee  and  the 
General  Assembly.  Each  group  has  a  distinct  role  in  the  development  of  IGES  and 
PDES  (or  STEP). 

The  IPO  Steering  Committee  is  the  martagement  committee  for  the  organization.  It 
sets  policies,  goals,  milestones,  and  deliverables  and  approves  procedures  and 
personnel  assignments.  The  General  Assembly  is  composed  of  27  technical 
committees  which  are  involved  in  the  techitical  development  of  both  IGES  and  STEP. 
The  IPO  is  administrated  by  the  National  Computer  Graphics  Association  (NCGA)  while 
National  institute  of  Standards  and  Techrwiogy  (NIST)  is  chartered  with  hosting  the 
chair  of  IPO. 

1 2^^  National  Initiattve  for  Product  Data  Exchange  (NlPDE): 

NlPDE  (Ref.  4)  is  an  industry-led.  government-facilitated  organization  established  to 
accelerate  product  data  exchange  (PDE)  development  and  implementation.  NlPDE 
works  to  exparxt  the  PDE  community,  unite  those  already  in  it  and  leverage  everyone's 
efforts.  Its  participants  include  companies,  corporate  consortia,  standards 
organizations,  and  government  agencies  who  agree  to  active  involvement  in  NlPDE 
programs. 

NlPDE  has  developed  a  PDE  Road  MAP  which  currently  includes  aerospace, 
automative,  electrical-electronics,  infrastructure,  shipbuilding  and  construction 
industries.  This  Road  Map  will  help  focus  efforts,  identify  voids,  and  provide  a  basis  to 
minimize  redundant  activities.  It  should  be  useful  to  both  standards  and  software 
developers,  as  well  as  vendors,  testers,  educators,  users,  and  procurement  managers. 

12.8.4  National  POES  Testbed: 

The  National  PDES  Testbed,  established  at  NIST  in  1988  as  a  part  of  the  U.S. 
Department  of  Defense  (DoD)  CALS  program,  is  a  publicly  accessible  facility  that 
supports  the  development  of  product  sharing  technologies  for  DoD,  other  government 
agencies,  and  industry.  The  PDES  Testbed  facility  comprises  laboratories,  computer 
hardware,  software  systems,  and  testing  tools. 

12.8.5  POES,  Inc.: 

PDES,  Inc.  was  formed  in  1988.  It  is  the  me^or  funded  STEP  development  activity  in 
the  US.  Twenty  national  and  international  companies  are  presently  participating  in 
PDES,  Inc.  The  goal  of  PDES.  Inc.  is  to  accelerate  the  development  and 
implementation  of  PDES.  The  South  Carolina  Research  Authority  (SCR/^  was 
awarded  the  contract  to  provide  management  support  PDES,  Inc.  members  share 
resources  and  costs  to  develop,  test,  and  implemerrt  STEP. 

12.8.6  Navy/Industry  Digital  Data  Exchange  Standards  Committee: 
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The  Navy/Industry  Digital  Data  Exchange  Standards  Committee  (NIDDESC)  is  a 
cost-sharing  venture  between  the  Naval  Sea  Systems  Command  (NAVSEA)  and  the 
shipbuilding  industry.  NIDDESC  has  subcommittees  devoted  to  specific  areas  of  digital 
data  transfer.  The  basic  objectives  are  to  develop  an  industry-wide  conserisus  on 
product  data  models  for  ship  structures  and  distribution  systems,  and  also  for  the  digital 
exchange  of  product  model  data.  Efforts  include  contributions  to  IQES,  STEP,  and 
the  analysis  ^  ship  production  data  flows. 

12.9  Reference  and  Implementation  Documentation: 

1.  DIS  10303  (STEP)  Standards,  initiai  Release,  May  1993 

2.  Mark  Palmer  and  Mitch  Gilbert,  "Guidelines  for  the  Development  and  Approval  of 
STEP  Application  Protocols",  WG5/P5  Working  Draft,  7  January  1993 

3.  ISO  TC184/SC4  "Reference  Manual*  (Draft),  October  1992 

4.  "Product  Baseline  Activities",  National  Initiative  for  Product  Data  Exchange,  Release 
1,  October  1992. 
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PROGRAM  CALS  SELF  ASSESSMENT  CHECKUST 


PROGRAM  DOCUMENTATION 


.'lit ;  UM.f.M-li-W  I 


1.  Do  acquisition/program  requirements  planning  documertts  (AP,  CMP,  NTP,  and  TEMP) 
establish  ciear  objectives  for  CALS? 

Reference:  DoDI  5000.2  (6-N) ,  SECNAVINST  5000.2,  and  OPNAVINST  41 20.5 

Guidance;  CALS  objectives  should  be  identified  as  a  set  of  methodologies  for  risk 
reduction,  acquisition  cycle  time  reduction  and  reduction  in  the  cost  of  data 
acquisition  arKf  ownership.  NAVSUP  Publication  594  offers  general  guidance  for 
the  acquisition  and  managemeni  of  technical  data  arxl  also  discusses  CALS 
objectives  in  general  terms.  OPNAVINST  4120.5  provides  specific  CALS  goals 
and  objectives  for  the  N2nry.. 

2.  Do  the  AP  and  supporting  program  management  documentation  such  as  the  TDMP  reflect 
planning  to  develop,  acquire,  maintain  and  use  technical  information  in  digital  form? 

Reference;  DoDI  5000.2  (6-N  and  9-B). 

3.  Has  a  Government  Concept  of  Operations  (GCO)  been  developed.  Is  the  GCO  identified  as 
Government  Furnished  Information  (GF!)  in  the  DEM/VAL  RFP. 

Reference:  SECNAVINST  5230.X 

Guidance:  MIL-HOBK-59  and  Acquisition  Guidance  for  Implementation  of  CALS 

4.  Has  the  program  obtained  or  planned  to  obtain  specific  proposals,  irK:iuding  costs  and 
schedule,  for; 

a.  Integration  of  contractor  technical  information  systems  and  processes  for 
engineering,  manufacturing  and  logistics  support. 

b.  Authorized  government  access  to  contractor  data  bases. 

c.  Delivery  of  technical  information  in  digital  form  using  computer-aided  acquisition 
and  logistics  support  standards  contained  in  MIL-STD-1840. 

Reference:  DoDI  5000.2  (6-N) 

5.  Has  a  CALS  Implementation  Plan  (CALSIP)  been  identified  as  a  proposal  requirement  of  the 
DEM/VAL  RFP  and/or  as  a  contract  deliverable  (either  as  a  CALSIP  or  as  a  section  within 
another  management  plan)? 

Reference:  SECNAVINST  5230.X 

Guidance:  MIL-HDBK-59  and  Acquisition  Guidance  for  Implementation  of  CALS 

6.  Does  CALS  implementation  planning  identify  how  the  program  will  interface  with  the  existing 
nd/or  evolving  Department  of  the  Navy  CALS  infrastructure? 

Reference:  DoDI  5000.2  (9-B),  OPNAVINST  4120.5 


Guidance: 


The  program  should  have  evaluated  whether  receiving  systems  are  in  place  for 
the  management  and  use  of  program  digital  technical  information  (Tl) .  Where 
the  planned  CALS  receiving  systems  are  not  in  place  at  the  time  of  technical 
information  delivery,  the  program  should  have  identified  interim  solutions  arKf 
required  resources  to  manage  and  use  digital  Tl. 

7.  Does  the  DEMA/AL  RFP  Statement  Of  Work  (SOW)  and  Contract  Data  Requirements  List 
(CDRLs)  require  the  delivery  of  technical  information  and  data  products  in  digital  form  using 
either  on-line  access  to  the  contractor  data  base  or  MIL-STD-1840. 

Reference:  DoDI  5000.2  (6-N  aruf  9-B) 

Guidance:  MIL-HDBK-59 

8.  Have  source  selection  criteria/evaluation  factors  been  established  that  give  increased 
consideration  to  contractor  proposals  that  denvir^rate  the  capability  to  develop  integrated, 
shared  data  base  environments  consisting  of  analysis  tools,  consistent  integrated  data  basris, 
and  engineering  processes  designed  to  utilize  digital  information. 

Reference:  DoDI  5000.2  (6-N) 

Guidance:  What  other  initiatives  has  the  program  undertaken  to  improve  acquisition  aiKf 

support  processes  through  CALS  implementation?  Examples  would  include 
acquisition  of  LSAR  in  digital  form;  clear  plarts  to  update  and  maintain  the  LSAR 
for  use  as  the  source  database  for  logistics  product  development/update; 
development  of  links  with  maintenance  information  feedback  systems  to 
automate  the  update  of  operation  and  maintenance  related  data  in  the 
appropriate  database;  and  use  of  logistics  R&D  to  identify  additional  CALS 
related  applications.  MIL-HDBK-59  provides  guidance. 

Milestone  II .  Devulopment  ADoroval 

1 .  Do  acquisition/program  requirements  documents  (AP,  CMP,  NTP  and  TEMP)  include  updated 
CALS  objectives. 

Reference:  DoDI  5000.2  (6-N)  and  SECNAVINST  5000.2 

2.  Do  the  AP  and  supporting  program  management  documentation  such  as  the  TDMP  reflect 
planning  to  develop,  acquire,  maintain  and  use  technical  information  in  digital  form? 

Reference:  DoDI  5000.2  (6-N  and  9-B) 

3.  Has  the  program  obtained  or  planned  to  obtain  specific  proposals,  including  costs  and 
schedule,  for: 


a.  Integration  of  contractor  technical  information  systems  and  processes  for 
engineering,  manufacturing  and  logistics  support 

b.  Authorized  government  access  to  contractor  data  bases 


c.  Delivery  of  technical  information  in  digital  form  using  computer-aided  acquisition 
and  logistics  support  standards  contained  in  MIL-STD-1840. 


Reference:  DoDI  5000.2  (6-N) 
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4.  Has  the  Government  Concept  of  Operations  (GCO)  been  updated  to  reflect  current 
requirements.  Is  the  GCO  identified  as  Government  Furnished  Information  (GFI)  in  the 
Engineering  &  Manufacturing  Development  (EMD)  RFP. 

Reference:  SECNAVINST  S230J( 

GuidarKe;  MIL-HDBK-59  and  Acquisition  GuidarKe  for  Implementation  of  CALS 

5.  Has  a  CALSIP  been  Identified  as  a  proposal  requirement  of  the  EMO  RFP  and/br  as  a 
cor^ract  deliverable  (either  as  a  CALSIP  or  as  a  section  within  arwther  management  plan). 

Reference:  SECNAVINST  5230J( 

Guidance:  MIL-HDBK-59  and  Acquisition  Guidance  for  implementation  of  CALS 

6.  Does  the  approved  CALSIP  identify  how  the  program  will  interface  with  the  existing  and/or 
evolving  Department  of  the  Navy  CALS  infrastructure? 

Reference:  DoDI  5000.2  (9-B) .  OPNAVINST  41 20.5 

Guid2ince:  The  program  should  have  evaluated  whether  receiving  systems  are  in  place  for 

the  management  and  use  of  program  digital  technical  information  (Tl).  Where 
the  planned  CALS  receiving  systems  are  not  in  place  at  the  time  of  technical 
information  delivery,  the  program  should  have  identified  interim  solutions  and 
required  resources  to  manage  and  use  digital  Tl. 

7.  Does  the  EMD  RFP  Statement  Of  Work  (SOW)  arid  Contract  Data  Requirenrrents  List 
(CDRLs)  require  the  delivery  of  technical  information  and  data  products  in  digital  form  using 
either  on-line  access  to  the  contractor  data  base  or  MIL-STD-1 840. 

Reference:  DoDI  5000.2  (6-N  and  9-B) 

Guidance:  MIL-HDBK-59 

8.  Have  source  selection  criteria/evaluation  factors  been  established  that  give  increased 
consideration  to  contractor  proposeUs  that  demonstrate  the  capability  to  develop  integrated, 
shared  data  base  environments  consisting  of  analysis  tools,  consistent  integrated  data  bases, 
and  engineering  processes  designed  to  utilize  digital  information. 

Reference:  DoDI  5000.2  (6-N),  (10-B,  C),  SECNAVINST  5000.2,  OPNAVINST  4120.5 

Guidance:  What  other  initiatives  has  the  program  undertaken  to  improve  acquisition  and 

support  processes  through  CALS  implementation?  Examples  would  include 
acquisition  of  LSAR  in  digital  form;  clear  plans  to  update  and  maintain  the  LSAR 
for  use  as  the  source  database  for  logistics  product  development/update; 
development  of  links  with  maintenance  information  feedback  systems  to 
automate  the  update  of  operation  and  maintenance  related  data  in  the 
appropriate  database;  and  use  of  logistics  R&D  to  identify  additional  CALS 
related  applications.  MIL-HDBK-59  provides  guidance. 

Milestone  III  -  Production  Approval. 

1 .  Do  acquisition/program  requirements  documents  (AP,  CMP,  NTP  and  TEMP)  include  updated 
CALS  objectives. 

Reference:  DoDI  5000.2  (6-N)  and  SECNAVINST  5000.2 
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2.  Oo  the  AP  and  supporting  program  management  documentation  such  as  the  TOMP  reflect 
planning  to  develop,  acquire,  maintain  and  use  technical  information  in  digital  form? 

RefererKe;  DoOl  5000.2  (6-N  eind  9-B) 

3.  Has  the  program  obtairred  or  planned  to  obtain  specific  proposals,  including  costs  and 
schedule,  to  evaluate  the  cost  effectiveness  (over  the  anticipated  life  cycle)  of: 

a.  Integration  of  contractor  technical  information  systems  arvl  processes  for 
engineering,  manufacturing  and  logistics  support 

b.  Authorized  government  access  to  contractor  data  bases 

c.  Delivery  of  technical  information  in  digital  form  using  computer-aided  acquisition 
and  logistics  support  standards  contained  in  MIL-STD-1840. 

Reference:  DoOl  5000.2  (6-N) 

4.  Has  the  Government  Concept  of  Operations  (GCO)  been  updated  to  reflect  current 
requirements.  Is  the  GCO  identified  as  Government  Furnished  Information  (GFI)  in  the 
Production  RFP. 

Reference:  SECNAVINST  5230.X 

Guidance:  MIL-HOBK-59  and  Acquisition  Guidance  for  Implementation  of  CALS 

5.  Has  a  CALSIP  been  identified  as  a  proposal  requirement  of  the  Production  RFP  and/or  as  a 
contract  deliverable  (either  as  a  CALSIP  or  as  a  section  within  another  management  plan). 

Reference:  SECNAVINST  5230.X 

Guidance:  MIL-HDBK-59  and  Acquisition  Guidance  for  implementation  of  CALS 

6.  Does  the  approved  CALSIP  identify  how  the  program  will  interface  with  the  existing  and/or 
evolving  Department  of  the  Navy  CALS  infrastructure? 

Reference:  DoDI  5000.2  (9-B) 

Guidance:  The  program  should  have  evaluated  whether  receiving  systems  are  in  place  for 

the  management  and  use  of  program  digital  technical  information  (Tl).  Where 
the  planned  CALS  receiving  systems  are  not  in  place  at  the  time  of  technical 
information  delivery,  the  program  should  have  identified  interim  solutions  and 
required  resources  to  manage  and  use  digital  Tl. 

7.  Does  the  Production  RFP  Statement  Of  Work  (SOW)  and  Contract  Data  Requirements  List 
(CDRLs)  require  the  delivery  of  technical  information  and  data  products  in  digital  form  using 
either  on-line  access  to  the  contractor  data  base  or  MIL-STD-1840. 

Reference:  DoDI  5000.2  (6-N  and  9-B) 

Guidance:  MIL-HDBK-59 

8.  Has  a  CITIS  Transition  Plan,  as  a  part  of  the  CALSIP,  been  developed  to  identify  how  the 
Contractor  will  transition  the  program's  digital  Tl  to  the  Government. 

Reference:  SECNAVINST  5230.X 

Guidance:  The  program  may  identify  the  CALSIP  as  a  proposal  requirement  of  the 

Production  RFP  and/or  as  a  contract  deliverable  (either  as  a  CALSIP  or  as  a 
section  within  another  management  plan).  MIL-STD-CITIS  provides  guidance. 

4 


9.  Have  source  selection  criteria/evaluation  factors  been  established  that  give  increased 
consideration  to  contractor  proposals  that  demonstrate  the  capability  to  develop  integrated, 
shared  database  environments  consisting  of  analysis  tools,  consistent  integrated  data  bases,  and 
engineering  processes  designed  to  utilize  digital  infomudion? 

Reference:  OoOl  5000.2  (6-N) 

Guidance:  What  other  initiatives  has  the  program  undertaken  to  improve  acquisition  arxl 

support  processes  through  CALS  implementation?  Examples  would  include 
acquisition  of  LSAR  in  digital  form;  dear  plans  to  update  arxl  maintain  the  LSAR 
for  use  as  the  source  database  for  logistics  product  deveiopment/update; 
development  of  links  with  maintenance  information  feedback  systems  to 
automate  the  update  of  operation  and  maintenance  related  data  in  the 
appropriate  database:  and  use  of  logistics  R&D  to  identify  additional  CALS 
related  applications.  MIL-HDBK-59  provides  guidance. 


Milestone  IV  •  Malor  Modification  Aporovat 

1 .  Does  the  CALS  infrastructure  support  the  maruigement  and  use  of  acquired  digital  technical 
information  (Tl).  If  the  infrastructure  is  not  in  place,  is  an  interim  solution  identified  and  the 
required  resources  available  to  manage  and  use  the  acquired  digital  data. 

Reference: 

Guidance: 

2.  Has  the  Contractor  transitioned  the  program's  digital  Tl  to  the  Government  in  accordance  with 
the  CmS  Transition  Plan? 

Reference:  SECNAVINST  5230.X 

Guidance:  MIL-STD-CITIS 
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TECHNICAL  MANUALS 


Mil— terw  I. 

1 .  Does  the  DEMA/AL  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirements  List 
(CORL)  require  that  TMs  be  developed  digitally  (using  CALS  specifications  MIL-O-28000,  MIL-M- 
28001,  MIL-R-28002.  MIL-0-28003  &  MiL-M-29532)  and  delivered  digitally  (using  MIL-STO- 
1840). 

Reference:  DoOl  S000.2  (9-B) 

GuidarKe:  MIL-HOBK-59 

Mil— tone  II. 

1 .  Does  the  EMD  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirements  List  (CDRL) 
require  that  TMs  be  developed  digitally  (using  CALS  specifications  MIL-D-28000.  MIL-M-28001, 
MIL-R-28002,  MIL-D-28003  &  MIL-M-29532)  and  delivered  digitally  (using  MIL-STD-1840). 

Reference:  DoDI  5000.2  (9-B) 

Guidance:  MIL-HOBK-59 

MU— tone  III. 

1 .  Does  the  Production  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirenrents  List 
(CDRL)  require  that  TMs  be  developed  digitally  (using  CALS  specifications  MIL-D-28000,  MIL-M- 
28001,  MIL-R-28002,  MIL-0-28003  &  MIL-M-29532)  and  delivered  digitally  (using  MIL-STD- 
1840). 

Reference:  OoOl  5000.2  (9-B) 

Guidance:  MIL-HOBK-59 

Milestone  IV 
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TECHNICAL  DATA  (DRAWINGS) 

Mltettanel- 


1 .  Does  the  OEM/VAL  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirements  List 
(CDRL)  require  that  Technical  Data  (Drawings)  be  developed  digitaily  (using  CALS  specifications 
MIL-D-28000,  MIL-M-28001,  MIL-R-28002.  MIL-D-28003  &  MIL-M-29532)  and  delivered  digitally 
(using  MIL-STD-1840). 

Reference:  DoDI  5000.2  (9-B) 

Guidance:  MIL-HDBKSg 

2.  Does  the  DEMA/AL  RFP  SOW  and  Technical  Manual  Contract  Requirement  require  the 
development  of  ILS  products,  such  as  technical  manuals  and  training  materials,  using  the 
engineering  drawing  database  as  the  primary  source  for  illustrations? 

Reference:  SECNAVINST  5230.X 

Mllwteng  tl- 

1 .  Does  the  EMD  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirements  List  (CDRL) 
require  that  Technical  Data  (Drawings)  be  developed  digitally  (using  CALS  specifications  MIL-D- 
28000,  MIL-M-28001,  MIL-R-28002,  MIL-D-28003  &  MIL-M-29532)  and  delivered  digitally  (using 
MtL-STD-1840). 

Reference:  DoDI  5000.2  (9-B) 

Guidance:  MIL-HDBK-59 

2.  Docs  the  EMD  RFP  SOW  and  Technical  Manual  Contract  Requirement  require  the 

development  of  ILS  products,  such  as  technical  manuals  and  training  materials,  using  the 
engineering  drawing  database  as  the  primary  source  for  illustrations? 

Reference:  SECNAVINST  5230.X 

Milestone  HI. 

1 .  Does  the  Production  RFP  Statement  of  Work  (SOW)  and  Contract  Data  Requirements  List 
(CDRL)  require  that  Technical  Data  (Drawings)  be  developed  digitally  (using  CALS  specifications 
MIL-D-28000,  MIL-M-28001,  MIL-R-28002.  MIL  D-28003  &  MIL-M-29532)  and  delivered  digitally 
(using  MiL-STD-1840). 

Reference:  DoDI  5000.2  (9-B) 

Guidance:  MIL-HDBK-59 

2.  Does  the  Production  RFP  SOW  and  Technical  Manual  Contract  Requirement  require  the 
development  of  ILS  products,  such  as  technical  manuals  and  training  materials,  using  the 
engineering  drawing  database  as  the  primary  source  for  illustrations? 

Reference:  SECNAVINST  5230.X 
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LOGISTICS  SUPPORT  ANALYSIS 


MUffttOPgl- 

1 .  Does  the  early  LSA  strategy  reflect  CALS  methodology? 

Reference:  SECNAVINST  5000.2 

2.  Does  CALS  implementation  planning  identify  the  requirement  for  and  the  extent  to  which  the 
LSAR  will  be  maintained  throughout  the  life  cycle  of  the  weapon  system? 

Reference:  OPNAVINST4120.5 

3.  Does  the  DEMA/AL  RFP  SOW  arid  Technical  Manual  Contract  Requirement  require  the 
development  of  ILS  products,  such  as  technical  manuals,  training  materials  and  provisioning 
documentation,  using  the  Logistic  Support  Analysis  Record  (LSAR)  as  the  primary  source 
database? 

Reference:  DoDI  5000.2  (7- A) 

Mitettciw  II- 

1 .  is  the  LSAR  being  used  as  the  primary  source  database  for  the  development  of  ILS  products, 
such  as  technical  manuals,  training  materials  and  provisioning  technical  documentation? 

Reference:  OoOl  5000.2  (7-A) 

2.  Does  CALS  implernentation  planning  identify  the  requirement  for  and  the  extent  to  which  the 
LSAR  will  be  maintained  throughout  the  life  cycle  of  the  weapon  system? 

Reference:  OPNAVINST  4120.5 

3.  Does  the  EMD  RFP  SOW  and  Technical  Manual  Contract  Requirement  require  the 
development  of  ILS  products,  such  as  technical  manuals,  training  materials  and  provisioning 
documentation,  using  the  Logistic  Support  Analysis  Record  (LSAR)  as  the  primary  source 
database? 

ReferefKe:  DoDI  5000.2  (7-A) 

Milestone  III. 

1 .  Is  the  LSAR  being  used  as  the  primary  source  database  for  the  development  and  creation  of 
ILS  products,  such  as  technical  manuals,  training  materials  and  provisioning  technical 
documentation? 

Reference:  DoDI  5000.2  (7-A) 


2.  Does  CALS  implementation  planning  identify  the  requirement  for  and  the  extent  to  which  the 
LSAR  will  be  maintained  throughout  the  life  cycle  of  the  weapon  system? 

Reference: 


8 


3.  Does  the  Production  RFP  SOW  and  Technical  Manual  Contract  Requirement  regime  the 
development  of  ILS  products,  such  as  technical  manuals,  training  materials  and  provisioning 
documentation,  using  the  Logistic  Support  Analysis  Record  (LSAR)  as  the  primary  sowce 
database? 

Reference:  DoOl  5000.2  (7-A) 


SUPPLY  SUPPORT 

Milestone  I. 

1.  PTDs 


MANPOWER.  PERSONNEL  AND  TRAINING 
Mllotten^  I- 

1 .  Curriculum  development 
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SECTION  1 1 


Points-Of-Contact  Listing 


CALS  IN  THE  ACQUISmON  PROCESS 
Naval  Forcaa  Perapactiva 
Don  CMS  AcquMaon  Woildng  Croup 

TMa  MoiM  AppMM  to  Mch  Phaaa  o(  Um  Dotonca 
SyNam  Acquiaaion  Procaaa 


OoOSOOOj 

(«NW) 
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CALS  POINTS-OF-CONTACT  USTING 


1.0  NAVY  ORGANIZATIONS 

Offic*  of  tho  Chlof  of  Naval  Operations 
Contact  Cdr.  Steve  Boyce 
Code:  N432C 

Phone:  (703)  695-1338  /  AV 

Headquarters  Marine  Corps,  D/CS  l&L 
Contact  Ms.  Kathy  Chambers 
Code:  LPS-2 

Phone:  (703)  696-1074  /  AV 

Naval  Sea  Systems  Command 
Contact  Mr.  Steve  Weinstein 
Code:  04TDC 

Phone:  (703)  602-1 060/1 061  /  AV  332-1 060/332-1061 

Naval  Air  Systems  Command 
Contact  Mr.  Shawn  Magiil 
Code:  41144 

Phone:  (703)  746-0841  /  AV  286-0841 

Space  and  Naval  Warfare  Systems  Command 

Contact  Mr.  Ernest  Weill 
Code:  222-3 

Phone:  (703)  602-6053  /  AV  332-6053 

Naval  Supply  Systems  Command 


Contact 

Cdr.  Nick  Wasiiewski 

Code: 

06A 

Phone: 

(703)  607-0661  /  AV  327-0661 

Contact 

Mr.  Hun  Kim 

Code: 

06A1 

Phone: 

(703)  607-2651  /  AV  327-2651 

Marine  Corps  Systems  Command 

Contact:  Mq'.  David  Garrard 
Code: 

Phone:  (703)  640-5871/5872  /  AV  278-5871/278-5872 

Naval  Printing  and  Publishing  Services 

Contact  Mr.  Steve  Sherman  /  Ms.  Ann  Bams 
Code:  Defense  Prirrting  and  Publishing  Services,  40 

Phone:  (202)  433-741 6  /  AV  288-741 6 
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2.0  NAVY  CALS  POINTS-OF-CONTACT  FOR  TECHNICAL  AND  ACQUISITiON 
SPECIALTIES 

2.1  Technical  Manuals 

Naval  Saa  Syatoma  Command 
Contact  Mr.  Phil  Hans 
Code;  04T03 

Phone:  (703)  602-8700  /  AV  332-8700 

Naval  Air  Systems  Command 
Contact  Mr.  Gerry  Gruden 
Code:  Naval  Air  Technical  Services  Fadiity.  0128 

Phone:  (215)  697-1158  /  AV  442-1158 

Space  and  Naval  Warfare  Systems  Command 
Contact  Ms.  Barbara  J.  Biis 
Code;  222-1 B 

Phone:  (703)  602-8483  /  AV  332-8483 

Naval  Supply  Systems  Command 
Contact  Ms.  Joyce  DeTolia 
Code:  31 1 B 

Phone:  (703)  607-0908  /  AV  327-0908 

Marine  Corps  Systems  Command 

Contact  Ms.  Jean  Opavits  /  Mr.  Doug  Jones 
Code:  PSD 

Phone:  (703)  640-4269  /  AV  278-4269 

2JZ  Interactive  Electronic  Technical  Manuals 
Naval  Sea  Systems  Command 


Contact 

Cdr.  Cliford  Alligod 

Code: 

04TDB 

Phone: 

(703)  602-0066  /  AV  332-0068 

Naval  Air  Systems  Command 

Contact 

Ms.  Cindy  Janowsky 

Code: 

41144B 

Phone: 

(703)  746-0696/0840  /  AV  286-0696/0840 

Space  and  Naval  Warfare  Systems  Command 

Contact 

Ms.  Barbara  J.  Biis 

Code: 

222-1 B 

Phone; 

(703)  602-8483  /  AV  332-8483 
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Marin*  Corps  Systsms  Command 
Contact:  Mr.  Doug  Jones 
Code:  PSD 

Phone:  (703)  640-4269  /  AV  278^269 

2J  Logistic  Support  Analysis 

Naval  Sea  Systsms  Command 
Contact  Mr.  Willie  Jones 
Code:  SEALOG,4211 

Phone:  (71 7)  790-3206  /  AV  430-3206 

Naval  Air  Systems  Comnumd 
Contact  Mr  Charles  Suthers 
Code:  NADEP  Norfolk.  32130 

Phone:  (804)  445-9079  /  AV  564-9079 

Space  and  Naval  Warfare  Systems  Command 
Contact  Mr.  Wilson  Sts^gers 
Code:  222-2B 

Phone:  (703)  602-8483/8482  /  AV  332-8482/8483 

Naval  Supply  Systsms  Command 
Corttact  Mr.  Mike  Schlelnkofer 
Code:  41241 

Phone:  (703)  607-0903  /  AV  327-0903 

Marine  Corps  Systems  Command 

Contact  Mr.  Clint  Davis 
Code:  PSL-B 

Phone:  (703)  640-5867  /  AV  278-5867 

2.4  Technical  Data  Packages 

Naval  Sea  Systems  Command 
Contact  Mr.  Harry  Felsen 
Code:  04TD 

Phone:  (703)  602-0068  /  AV  332-0068 

Naval  Air  Systsms  Command 
Contact  Mr.  Dick  Gentillo 
Code:  NATSF,  Washington  Navy  Yard 

Phone:  (202)  433-3253  /  AV  288-3253 

Space  and  Naval  Warfare  Systems  Command 

Contact  Ms.  Linda  J.  Berry 
Code:  222-1 

Phone:  (703)  602-8483  /  AV  332-8483 
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Marin*  Corps  Systems  Command 
Contact  Mr.  Robin  Fait 
Coda:  PSD-D 

Phone:  (703)  640-4372  /  AV  278^372 


4 


3X)  CALS  SYSTEM  PROGRAM  MAMAGERS 


Advanced  Industrial  Managamant  (AIM) 

Contact:  Mr.  Frank  Bankas 

Code:  NAVSEA.  0721 

Phona:  (703)  602-431 1  /  AV  332-431 1 

Contact  Mr.  Richard  Claus 

Coda:  NAVSEA,  0721 

Phona:  (703)602-4314 /AV  332-4314 

Advanced  Technical  Information  Support  (ATIS) 

Contact  Ms.  Rose  Digeronimo 
Coda:  NAVSEA.  04T02 

Phona:  (703)  602-0068/1924  /  AV  332-0068  / 1924 

Authoring  Instructional  Matarlals  (AIM(T)) 

Contact  Mr.  Roy  Nelson 

Coda:  NAVSE/L  04MP51 

Phona:  (202)  433-2532  /  AV  288-2532 

Computer-Aided  Design  (CAD)  2 

Naval  Sea  Systams  Command 
Contact  Mr.  Craig  Carlson 
Code:  04iS1 

Phone:  (703)  602-8735  /  AV  332-8735 

Naval  Air  Systams  Command 
Contact  Mr.  David  Raup 
Code:  NAVAIR,  41144D 

Phone:  (703)  692-5661/5690  /  AV  222-5661/5690 

Naval  Supply  Systams  Command 
Contact  Ms.  Ann  Bams 

Code:  Defense  Printing  and  Publishing  Services  41 

Phone:  (202)  433-741 6  /  AV  288-741 6 

Space  and  Naval  Warfare  Systams  Command 
Contact  Mr.  Ernest  Welti 
Code:  222-3 

Phone:  (703)  602-6053  /  AV  332-6053 

Configuration  and  Logistics  Information  Program  (CUP) 
Marina  Corps 

Contact  Ms.  Garland  Rowland 

Code:  MARCORLOGBASES,  Albany.  GA.  (EDLO) 

Phone:  (912)  439-6407  /  AV  567-6407 
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Naval  Air  Systama  Command 
Contact  Mr.  Andrew  Darby 
Code:  41142 

Phone:  (703)  692-5661/5690  /  AV  222-5661/5690 

Electronic  Technical  PubUahlng  Syatem  (ETPS) 

Contact  Ms.  Jean  Oravits 

Code:  Marine  Corps  System  Command.  PSD 

Phone:  (703)  640-4570  /  AV  278-4570 

Engineering  Data  Management  Information  and  Control  Syatam  (EDMICS) 

Naval  Supply  Syatama  Command 
Contact  Mr.  Paul  Schmitt 
Code:  NAVSUP,  641A 

Phone:  (703)  607-3298  /  AV  327-3298 

Marine  Corps  Systama  Command 
Contact  Mr.  Tim  Parker 
Code:  PSE 

Phone:  (703)  640-4588  /  AV  278-4588 

Enhanced  Ships  Technical  Publication  System  (ESTEPS) 

Contact  Mr.  Phil  Hans 

Code:  NAVSEA.  04TD3 

Phone:  (703)  602-8700  /  AV  332-8700 

ICAPS 

Contact  Lcdr.  Ray  Fallon 

Code:  NAVSE/^  04MS3 

Phone:  (703)  607-2456  /  AV  327-2456 

Joint  Computer-Aided  Acquisition  and  Logistic  Support  (JCAtS) 

Contact  Cdr.  Nick  Wasiiewski 

Code:  NAVSUP,  06A 

Phone:  (703)  607-0061  /  AV  327-0061 

Logistics  Planning  and  Requirements  Simplification  System  (LOGPARS) 

Naval  Sea  Systems  Command 
Contact  Mr.  Tom  Gagiione 
Code:  04E7 

Phone:  (703)  602-9177  /  332-9177 

Naval  /Ur  Systems  Command 
Contact  Ms.  Dee  Debloif 
Code:  41111A 

Phone:  (703)  692-9266  /  AV  222-9266 
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Naval  Aviation  Logistica  Data  Analyaia  Program  (NALDA) 

Contact  Mr.  Steve  Bernstein 
Code:  NAVAIR.  41143 

Phone:  (703)  692-5661/5690  /  AV  222-5661/5690 

Naval  Publiahing  on  Demand  (NPODS) 

Contact  Mr.  Steve  Sherman  /  Ms.  Ann  Bams 
Code:  Defense  Printing  arxi  Publishing  Services.  40 

Phone:  (202)  433-7416  /  AV  288-7416 

Navy  Engineering  Drawing  Asset  Locator  System  (NEDALS) 

Space  and  Naval  Warfare  Systems  Command 
Contact  Ms.  Judith  L  Schutrum 
Code:  222-1A 

Phone:  (703)  602-7537  /  AV  332-7537 

Naval  Sea  Systems  Command 
Contact  Mr.  Harry  Felsen 
Code:  04TD 

Phone:  (703)  602-0068  /  AV  332-0068 

Ships  Configuration  and  Logistics  Support  Information  System  (SCLSIS) 
Contact  Mr.  Phillip  Stiles 
Code:  NAVSEA.  04TO1 

Phone:  (703)  602-2160  /  AV  332-2160 

Shipboard  Non-Technical  ADP  Program  III  (SNAP  IIQ 
Contact  Mr.  P.  Davenport 
Code:  SPAWAR 

Phone:  (703)  602-0107  /  AV  332-0107 

Solidtatlon  Package  Automation  (SPA) 

Contact  Mr.  Steve  Sherman  /  Ms.  Ann  Bams 
Code:  Defense  Printing  arKi  Publishing  Services.  40 

Phone:  (20^  433-7416  /  AV  288-7416 

Technical  Data  Centar/Configuration  Management  System  (TDC/CMS) 

Navy: 

Contact  Mr.  William  Cheaiese 

Code:  107 

Phone:  (804)  396-0724 

Marine  Corps: 

Contact  Capt  Chris  Ekman 

Code:  MARCORLOGBASES.  Albany,  GA  (EDLO) 

Phone-  (912)  439-6651 
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Technical  Data  Cantar/Elactronic  Technical  Manual  System 
Contact  Mr.  Bill  Estes 
Code:  107 

Phone:  (804)  396^74 

Technical  Manual  Print  on  Demand  System  (TMPODS) 
Contact  Mr.  Steve  Sherman  /  Ms.  Ann  Bams 
Code:  Defense  Printing  and  PubBshir^)  Services,  40 

Phone:  (202)  433-7416 

DSN:  288-7416 
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1.0  INTRODUCTION 


The  Navy/Marine  Corps  Manager^  Desktop  Guide  for  CALS  Implementation  provides 
decision  templates  for  selecting  the  most  effective  digital  data  formats  and  media 
formats.  Digital  data  includes  the  technical  data  package  (TDP),  technical  manuals 
(TM),  and  the  logistic  support  analysis  record  (LSAR).  Effective  acquisition  and  use  of 
digital  data  can  only  be  accomplished  with  full  consideration  of  the  ability  of  Naval 
activities  to  receive,  store,  distribute,  and  use  the  digital  data 

DoDI  5000.2,  Part  9,  Section  B  states  that  'Ihe  defense  system  program  office  win 
ensure  that  all  recipients  of  digitai  data  will  have  the  cajpabiUty  to  receive,  store, 
and  maintain  the  provided  data*  The  materials  and  equipment  required  for  receiving, 
storing,  and  maintaining  data  constitutes  the  infrastructure  requirements  of  Computer- 
aided  Acquisition  arxl  Logistic  Support  (CALS).  This  infrastructure  requirement  is  a  key 
consideration  in  impiementing  the  CALS  strategy  on  any  defense  S)^em  acquisition. 
Deficiencies  in  the  Government's  infrastructure  may  require  investments  by  the 
Acquisition  Manager  to  implement  the  CALS  strategy  effectively. 

1.1  Scope 

Most  defense  system  investment  requirements  for  hardware,  software,  and 
telecommunications  are  within  the  discretion  of  the  defense  system  Acquisition 
Manager.  Other  infrastructure  investments  are  the  responsibility  of  the  supporting 
Defense  Business  Operating  Fund  (DBOF)  activities.  This  document  links  selected 
digital  data  and  media  formats  to  the  appropriate  infrastructure  requirements. 

1.2  Purpose 

This  document  is  intended  to  provide  Navy/Marine  Corps  Acquisition  Managers  with  an 
overview  of  hardware,  software,  and  telecommunications  requirements  for  the  creation, 
managemenL  and  use  of  digital  technical  data  Section  3  discusses  the  general 
considerations  and  requirements  of  a  computer  system  infrastructure.  Section  4 
describes  the  specific  requirements  that  are  dependent  on  the  data  type,  data  format, 
and  user  function. 

1.3  infrastructure  Resource  Planning 

The  Acquisition  Manager  should  plan  to  fund  an  infrastructure  modernization  program. 
The  Acquisition  Manager  should  ^an  infrastructure  requirements  such  that  funding  can 
be  set  aside  to  be  used  when  the  infrastructure  irrvestment  is  required.  This  approach 
will  utilize  program  funding  and  resources  better.  Additional  guidance  on  infrastructure 
resource  planning  can  be  found  in  MIL-HDBK-59. 
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2.0  REFERENCES 


2.1  Acronyms 

A  complete  list  of  acronyms  used  throughout  the  desktop  guide  is  in  Appendix  A.  The 
following  acronyms  are  used  in  this  section  of  the  guide. 


AOMAPS 

ADP 

AIM 

ANSI 

APPS 

ASCII 

ASIC 

ATIS 

CAD 

CAD-2 

CALS 

ccrrr 

CD 

CGM 

cms 

CPU 

DAT 

DBOF 

DoD 

DODI 

DOS 

DPI 

DSN 

EDIF 

FAX 

G-byte 

IEEE 

lETM 

IGES 

ILS 

IPC 

JEDMICS 

LAN 

LSAR 

MIS 

MRSA 

NAVAIR 

NAVSEA 

NEDALS 

NFS 

PC 

PDL 

PWB 

QIC 


Automated  Document  Management  and  Publishing  System 

Automated  Data  Processing 

Advanced  Industrial  Management 

American  National  Standard  Institute 

Advanced  Planning  and  Packaging  Support 

American  Standards  Code  for  infoimation  Interchange 

Application-SpecHic  Integrated  Circuita 

Advanced  Tecftfilcal  Irrformation  System 

Computer  Aided  Design 

Computer  Aided  Design  (Second  Acquisition) 

Computer-aided  Acquisition  and  Logistic  Support 
Committee  for  International  Telephone  and  Telegraph 
Compact  Disk 

Computer  Graphics  Metafile 

Contractor  Integrated  Technicsd  Information  Senrice 

Central  Processing  Unit 

Digital  Audio  Tape 

Defense  Business  Operating  Fund 

Department  of  Defense 

DoD  Institute 

Disk  Operating  System 

Dots  Per  Inch 

Defense  Support  Network 

Ele;itronic  Design  Interface  Format 

Facsimile 

Gigabytes 

Institute  of  Electrical  arxl  Eiecfronic  Engineers 

Interactive  Electronic  Technical  M.snual 

Initial  Graphics  Exchange  Spedfication 

Integrated  Logistic  Support 

Institute  for  interconnecting  and  Packaging 

Joint  Engineering  Data  Management  Information  and  Control  System 

Local  Area  Network 

Logistic  Support  Analysis  Record 

Management  Information  System 

Materiel  Readiness  Support  Activity 

Naval  Air  Systems  Command  Headquarters 

Naval  Sea  Systems  Command  Headquarters 

Navy  Engineering  Drawing  Asset  Locator  System 

Network  File  System 

Personal  Computer 

Page  Description  Language 

Printed  Wiring  Board 

Quarter  lrK;h  Cartridge 
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RISC 

ROM 

SGML 

SPAWAR 

SPCC 

TOP 

TM 

TMPODS 

UHDL 

UHSIC 

WAN 

WORM 


Reduced  Instruction  Set  Computing 
Read  Only  Memory 

Standard  Generalized  Markup  Lar^uage 
Space  and  Navy  Warfare  Sy^ems  Command 
Ships  Parts  Coritrol  Center 
Terreal  Data  Packa^ 

Technical  Manuals 

Technical  Manuals  Print-On-Demand  System 
UHSIC  Hardware  Description  Language 
Ultra  High  Speed  Integrated  Circuits 
Wide  Area  Network 
Write  Once  Read  Many 


22  DefinHions 


Definitions  used  in  this  section  and  throughout  the  Desktop  Guide  are  in  Appendix  A: 
Definitions. 


22  Applicable  Documents 

Documents  referenced  in  this  section  and  throughout  the  desktop  guide  are  listed  in 
Appendix  A:  Applicable  Documents. 
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3.0  GENERAL  CONSIDERATIONS 


If  data  users  do  not  have  access  to  the  appropriate  hardware,  software,  and 
telecommunications  equipment,  working  in  a  digital  data  envirorvnent  can  become  an 
obstacle  rather  than  an  advantage.  In  the  past,  Isiavy/Marine  Corps  Acquisition 
Managers  have  contracted  for  digital  data  deliverables  only  to  find  an  inadequate  or 
nonexisting  digital  data  infrastructure  capability.  The  computer  hardware  must  have  the 
appropriate  processing  speed  and  display  capability  to  run  the  application  software 
adequately.  The  application  software  must  perfonn  specific  tasks  on  the  digital  data 
that  are  required  by  the  user.  Rather  than  recreate  the  data,  the  appropriate  computer 
networking  system  should  allow  the  users  to  share  data  and  resources,  and 
telecommunications  equipment  should  allow  users  to  transfer  digital  data  easily. 

After  reading  the  first  1 1  sectiorts  of  the  Navy/Msuine  Corps  Mar)ager‘s  Desktop  Guide 
for  CALS  Implementation,  a  Navy/Marine  Corps  Acquisition  Manager  should  have  an 
implementation  approach  for  data  type,  process,  format,  and  deiivery/access  method. 
With  this  information,  infrastructure  requirements  can  be  identified.  Each  decision  will 
affect  the  life-cycle  costs  of  a  program  and  the  cost  of  the  program's  computer 
infrastructure.  Humaivinterpretable  data  formats,  such  as  page  description  language 
(POL)  and  raster,  may  not  be  suitable  as  source  data  for  other  applications. 
Processabie  data  formats  can  be  integrated  with  other  digital  data  to  reduce  the  total 
life-cyde  costs. 

The  following  sections  address  various  topics  of  consideration  for  a  computer 
infrastructure: 

Computer  Architecture 
Computer  Operating  System 
Storage  Devices 
Output  Devices 

Computer  Graphics  and  Monitors 
Network  Devices 
Application  Software 
Software  Licensing 
Network  Protocols 
Local  Area  Networks  (LANs) 

Wide  Area  Networks  (WANs) 

Contractor  Integrated  Technical  Information  Service  (CITIS) 

In  Section  4.0,  Infrastructure  Requirements,  these  topics  are  used  as  a  basis  to  discuss 
the  specific  hardware,  software,  and  telecommunication  requirements  of  a  program. 
Also  included  are  several  decision  diagrams  to  help  the  Acquisition  Manager. 

3.1  Hardware  Considerations 

Computer  hardware  consists  of  the  computer  processor,  memory,  monitor,  storage 
devices,  and  input  devices.  Each  computer  should  be  tailored  to  fit  the  need  of  the 
main  application.  Computational  intensive  applications  such  as  mechanical  solid 
modeling  or  engineering  simulation  will  require  a  larger  amount  of  memory  than  general 
text  and  2-D  graphics-based  applications.  Each  application  requires  a  distinct  amount 
of  hard  disk  space  for  data  storage.  Raster  images  and  simulation  models  tend  to 
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require  more  disk  space  than  vector-based  databases  such  as  Computer  Graphics 
Metafile  (CGM)  or  Computer  Aided  Design  (CAD)  files. 

3.1.1  Computer  Architecture 


Most  engineering  and  business  single  user  computers  use  either  an  80386/80486- 
based  processor,  a  6803Q/68040-based  processor,  or  a  Reduced  Instruction  Set 
Computing  (RISC)  based  processor.  Each  computer  is  designed  to  meet  a  specific 
requirement  In  many  cases,  the  computer  architecture  is  driven  by  the  choice  of 
application  software  needed  to  perform  a  specific  task.  For  this  reason,  the  sofhvare 
selected  may  be  the  most  important  decision  made. 


The  80386/80486  and  68030/68040  personal  computers  (PCs)  are  the  most  widely 
used  computers  and  are  ideal  for  noncomputational  intensive  appiicabons  that  require 
lew-  to  medium-graphic  dispis^.  The  RISC  workstations  are  widely  used  in 
engineering  and  technical  publishing  applications  thr>t  require  either  a  p>owerful 
processor  for  extensive  calcutations  or  a  high-resoiutlon  graphics  display  for  document 
editing.  A  "diskless*  RISC  workstation  may  provide  a  low-cost  solution  to  some 
engineering  computing  needs.  These  workstations  typically  have  a  small  hard  disk  for 
the  operating  sy^em  while  the  application  software  and  user  files  are  loaded  from  a 
server  workstation  that  is  connected  by  a  network.  A  third  option  is  a  graphic  display 
workstation  that  supports  the  X-window  Modf  standard.  However,  a  PC  with  X-wlndow 
emulation  software  may  provide  the  same  features  at  a  lower  cost.  The  standard 
options  for  each  type  of  computer  is  presented  in  table  1 . 


TABLE  1.  Standard  Options  for  PC  Types 


Personai 

Computer 

Typel 

Windows 

Workstation 

Type  2 

Rise  Workstation 
Type  3 

Processor 

386  DX  -  33/68030 

486  DX  -  33/  68040 

RISC  Workstation 

8  Mb 

16Mb 

32Mb 

Media 

Hard  Drive 

200  Mb 

350  Mb 

500  Mb 

3.5  &  5.25 

3.5  &  5.25 

3.5 

Tape  Drive 

No 

Optional 

Yes 

CD  Drive 

Optional 

Yes 

Yes 

Optional 

Optional 

Monitor 

15*-ir  Fiat  SVGA 

17*-19*  Flat  SVGA 

19*-2rHigh  Res 

Typicai 

Cost 

$1,500  to  $8,000 

$3,000  to 
$10,000 

$5,000  to 
$50,000 

3.1.2  Computer  Operating  System 

The  operating  system  is  the  shell  that  interprets  the  user's  commands  and  translates 
them  into  machine  code  to  control  the  computer's  resources.  The  computer's  internal 
clock,  memory,  central  processing  unit  (CPU),  terminal,  and  other  peripherals  are 
controlled  by  the  operating  system.  The  three  major  distinctions  among  operating 
systems  are  the  internal  throughput  bit  size,  the  amount  of  available  memory,  and  the 
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ability  for  multitasking.  Each  of  these  factors  comrols  the  effectiveness  of  a  computer 
for  a  particular  user. 

Any  computer  can  run  an  operating  system  with  the  same  internal  bus  size  or  smaller, 
but  the  computer  cannot  run  an  operating  system  with  a  larger  bus  size.  The  80286 
and  80386SX  computers  are  only  16-bit  computers  and  cannot  be  upgraded  to  any  32- 
bit  operating  system.  The  80386DX  and  80486  computers  have  a  32-bit  internal  bus 
as  do  most  RISC  workstations.  A  few  of  the  high-end  RISC  workstations  have  a  64-bit 
internal  bus  and  will  be  compatible  with  a  64-bit  operating  system. 

Two  operating  systems  are  available  for  80386/80436-based  PCs.  DOS  was  the  first 
major  operating  system  for  a  PC  and  continues  to  be  the  standard.  DOS  is  only  an  8- 
bit  or  16-bit  operating  system  and  does  not  offer  true  multitasking.  OS/2  was 
introduced  a  few  years  ago  and  offered  users  multitasking  and  a  32-bit  operating 
system.  Windows  hTT  is  similar  to  System  7.  discussed  in  following  paragraph,  and 
offers  many  advantages  compared  to  DOS.  The  largest  benefit  is  that  Windows  hTT  wUI 
be  available  on  PCs  and  RISC-based  workstations.  This  will  allow  the  engineering 
users  access  to  the  same  application  software  on  a  RISC  workstation  that  most 
business  users  have  on  a  PC. 

A  popular  operating  system  used  for  the  68000  series  processor  is  System  7,  which  is 
a  true  windowing  system  with  32-bit  multitasking  capabilities.  This  operating  system 
has  attained  popularity  due  to  its  ability  to  meet  the  demands  of  both  beginner  and 
expert  computer  users.  The  operating  system  has  strict  hardware/software  standards 
that  reduce  compatibility  and  installation  problems.  However,  the  cost  of  such  systems 
is  generally  10-20  percent  higher  than  similar  Windowing  systems. 

Most  RISC  workstations  currently  have  a  UNIX  operating  system  based  on  System  V 
UNIX  or  Berkeley  BSD  4.4  UNIX  that  is  POSIX  compliant  Each  operating  system 
provided  with  RISC  workstations  is  unique,  but  most  will  run  application  programs  that 
were  compiled  using  System  V  or  Berkeley  BSD  UNIX.  Both  the  Automated  Document 
Management  System  (ADMAPS)  and  CAD-2  program  specified  a  POSIX  operating 
system  with  a  Motif  standard  graphical  user  interface. 

Three  new  POSIX-compliant  operating  systems  have  just  been  released  or  will  be  in 
the  next  year.  OSF/1.0,  OPEN  VMS,  and  Windows  NT  are  new  operating  systems  that 
are  designed  to  allow  users  a  greater  variety  of  application  softwve.  Windows  NT  is 
designed  to  allow  users  of  the  RISC-based  computer  and  80486-processor-based- 
computer  to  run  the  same  operating  system  and  the  same  versions  of  application 
software. 

3.1.3  System  Backup 

System  backup  is  very  important  to  the  Acquisition  Manager.  If  managed  properly, 
sterns  can  be  designed  such  that  even  a  catastrophic  loss  of  data  can  be  recovered 
in  a  relatively  short  period  of  time.  To  do  this,  the  Acquisition  Manager  should  address 
areas  such  as  hard  drive  or  CPU  failure,  lightning  strike,  fire,  or  damaging  storm  in  a 
disaster  recovery  plan. 

Backup  of  a  system  should  include  a  practical  means  to  back  up  system  data  This  is  a 
function  that  should  be  easy  to  accomplish  and  convenient  to  the  users.  If  a  system 
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does  not  have  a  convenient  backup  system,  the  user  will  be  unlikely  to  back  up 
regularly  and,  thus,  risk  catastrophic  loss  of  program  data.  An  acceptable  means  to 
archive  system  and  program  data  is  to  use  a  tape  backup  system. 

3.1.4  Physical  Media 

Each  computer  system  needs  the  appropriate  amount  of  data  storage  capacity  to  allow 
users  access  to  all  areas  of  project  data.  This  disk  space  can  reside  on  each  computer 
or  on  a  network  file  smyer.  Storage  technology  is  constantly  changing,  and  the 
Acquisition  Manager  should  understand  that  the  physical  media  addressed  below  is 
provided  as  a  guideline  but  does  not  necesssully  imply  that  only  the  following 
technology  should  be  used  in  builcfing  infrastnjcture.  When  evaluating  whether  to  use 
new  technology,  the  Acquisition  Manager  should  assure  compatibility  with  other 
equipment  of  the  same  technology  or  with  older,  less  sophisticated  media.  Rgure  1 
displays  samples  of  physical  media 


RGURE  1.  Examples  of  Physical  Media 

3.1 .4.1  Magnetic  Media 

Magnetic  disk  drives  are  available  for  most  computer  system ..  Magnetic  disk  drives 
can  store  from  200  to  4,000  megabytes  and  should  be  ANSI  SCSI  or  IDE  compatible. 
SCSI  provides  compatibility  and  allows  for  expansion  when  greater  disk  space  is 
required.  Magnetic  disks  can  be  used  to  transfer  data  when  required.  The  most 
common  magnetic  disk  to  transfer  data  is  the  3.5  inch  and  5.25  inch  magnetic  disk. 
The  5.25  inch  can  hold  up  to  1 .2Mb  of  data,  and  the  3.5  inch  can  hold  up  to  1 .44Mb. 
Using  magnetic  disks  to  transfer  data  should  only  be  considered  when  the  total  data 
does  not  exceed  10Mb. 
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When  transferring  over  lOMb  of  data,  a  9-track  computer  tape  or  Quarter  Inch 
Cartridge  (QIC)  tape  would  be  better  suited  (MIL-STD-1B40).  The  standard  9-track 
tape  can  store  approximately  240Mb  of  data  compared  to  500mb  with  the  QIC.  The 
exact  configuration  of  the  tape  format  can  greatly  affect  the  capacity  of  the  tape.  Tape 
drives  that  accept  tape  cartridges  are  easier  to  obtain  and  integrate  into  a  desktop 
computer  system.  However,  the  Acquisition  Manager  should  confirm  that  tape  formats 
are  compatible. 

An  alternative  technology  to  9-track  tape  or  an  optical  drive  (paragraph  3. 1.4.2)  is  the 
Digital  Audio  Tape  (DA'O  drive.  DAT  drives  can  store  up  to  5  Gigabytes  (Gbyte)  of 
data.  The  tapes  are  small  and  are  easily  integrated  into  the  desktop  environment  This 
avoids  capacity  problems  that  are  sometimes  encountered  in  9-track  and  optical  drives. 

3.1 .4.2  Optical  Media 

Optical  drives  are  readify  available  and  come  in  many  different  types  and  sizes.  The 
most  common  optical  drive  is  the  5.25  inch  Compact  Disk  (CD)  Read  Only  Memory 
(ROM)  drive.  These  drives  are  used  for  end  user  systems  similar  to  Advanced 
Technical  Information  System  (ATIS).  A  Write  Orx:e  Read  Many  (WORM)  optical  disk 
system  should  be  considered  for  storing  the  final  deliverable  digital  data  for  a  large 
project  Optical  disks  can  store  up  to  200  Gbytes.  This  will  provide  the  project  with  a 
nonerasable  copy  of  the  data  that  can  help  in  configuration  control.  However,  all 
WORM  optical  disk  systems  do  not  produce  the  same  format  as  CD,  and  compatibility 
with  the  end  user  should  be  verified. 

3.1  Output  Devices 

Each  computer  user  will  need  access  to  a  printer  and/or  a  plotter.  These  devices  can 
be  set  up  on  a  LAN  rather  than  directly  to  a  specific  computer,  so  that  netvrork  users 
can  share  the  devices.  Prirrters  are  generally  used  to  produce  “A*  or  "B"  (ANSI  Y14.1- 
80)  size  documents.  Plotters  are  used  to  create  up  to  ’J”  size  documents.  Aperture 
card  plotters  are  also  available  and  are  used  to  plot  the  image  to  an  aperture  card  and 
inscribe  the  aperture  cards  keypunch  data 

An  *A*  size  PostScript  compatible  laser  printer  is  the  standard  printer  recommended  for 
general  use.  The  printer  should  have  a  mirumum  resolution  of  300  by  300  Dots  Per 
Inch  (DPI)  and  a  minimum  print  speed  of  four  to  eight  pages  per  minute.  An  *A/B*  size 
laser  printer  would  be  better  suited  to  print  engineering  drawings.  Most  drawings  are 
legible  when  printed  on  "B*  size  paper. 
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FIGURE  2.  Standard  Laser  Printer 

The  two  main  types  of  plotters  are  electrostatic  and  pen  plotters.  Electrostatic  "E*  size 
plotters  are  recommended  for  engineers  involved  in  the  creation  and  review  of 
engirreering  documents  or  when  there  is  a  requirement  to  plot  up  to  *P  size  raster 
drawings.  A  pen  plotter  may  suffice,  but  these  plotters  can  take  up  to  30  minutes  to 
print  a  vector  drawing  versus  only  1  to  2  minutes  for  an  electrostatic  plotter.  Pen 
plotters  cannot  be  used  to  plot  raster  images.  Electrostatic  plotters  generally  cost 
between  $5,000  and  $12,000;  pen  plotters  cost  about  $4,000. 

3.1.6  Computer  Graphics  and  Monitors 

The  resolution  and  monitor  size  are  important  consideratior«  when  choosing  the  proper 
monitor.  Most  users  who  work  with  graphical  data  such  as  engineering  drawings  or 
technical  illustrations  will  be  more  efficient  with  a  higtvresolution,  19-inch  monitor  This 
is  especially  true  when  working  with  raster  files.  A  larger  monitor  may  eliminate  the 
need  to  zoom  in  on  a  section  of  the  drawing  or  illustration.  A  14-  to  16-inch  monitor  is 
suited  only  for  general  Windows  applications  and  is  not  recommended  for  reviewing 
drawings  or  illustrations. 

An  option  for  some  RISC-based  workstations  is  real-time,  3-D  graphic  manipulations. 
This  allows  the  user  to  rotate  and/or  scale  the  view  of  the  object  in  real  time.  Any 
engineer  performing  solid  modeling  or  finite  element  analysis  will  increase  productivity 
on  the  workstation  with  this  option.  Screen  redraws  'or  complex  images  can  take  up  to 
several  minutes  with  a  standard  graphics  option  but  can  be  performed  instantaneously 
with  the  30  graphic  processors. 

3.1.7  Network  Devices 

Network  devices  include  equipment  that  is  required  to  connect  a  single  user  station  to 
an  existing  network  or  to  connect  two  or  more  networks  together.  Examples  of  this  type 
of  equipment  usually  are  network  cards,  bridges,  and  routers. 
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The  basic  requirements  to  create  a  single  LAN  are  an  Ethernet  board  for  each 
computer  and  the  coaxial  or  twisted-pair  cable  to  connect  each  computer.  Network 
bridges  can  be  added  to  the  LAN,  to  connect  to  other  LANs  or  manage  the  LAN 
electronic  message  traffic.  Network  terminal  servers  allow  termiruds,  modems,  and 
printers  to  be  connected  into  the  LAN.  Network  routers  enable  remote  LANs  to  be 
connected  or  the  LAN  to  connect  to  a  WAN.  All  r^etwork  devices  should  support  the 
Ethernet  V2.0  and  IEEE  802.3  standards.  Due  to  LAN  configuration  complexity  and 
variety,  the  Acquisition  Manager  should  discuss  infrastructure  requirements  with  the 
supporting  activity  Automated  Data  Processing  (ADP)  martager  before  purchasing  any 
LAN  equipment. 

3.1.8  Input  Devices 

There  are  many  different  ways  to  provided  input  to  a  computer  system.  One  of  the 
most  basic  input  devices  is  a  keyboard.  There  are  many  different  arrangements; 
however,  the  industry  standard  is  the  101 -key  type.  Additioral  devices  include  mice, 
track  balls,  digitizing  tablets,  light  pens,  and  scanners.  With  the  exception  of  the 
scanner,  all  the  previous  devices  generate  data  with  the  user's  guidarx^e. 


101  Type  Keyboard 


Digitizing  Tablet 


Trackball 


Mouse 


Page  Scanner 


FIGURE  3.  Examples  of  Input  Devices 

The  technology  of  scanners  has  greatly  increased  in  the  past  few  years  and  can  add 
speed  in  the  generation  of  technical  data  Scanners  can  have  many  features  including 
color,  gray  scale,  line  ait,  and  a  host  of  others.  As  a  general  rule,  the  more  features 
and  higher  detail  of  the  image,  the  more  disk  space  is  required.  There  are  definite 
ranges  where  there  is  a  point  of  diminishing  return  comparing  quality  of  image  vs.  size 
of  image  Attention  should  be  made  to  this  aspect,  because,  not  only  will  a  large  image 
consume  a  large  amount  of  disk  space,  but  it  will  also  slow  the  speed  of  the  computer 
when  the  graphic  is  to  be  displayed.  There  are  many  different  types  and  sizes  of 
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scanners  available  to  the  Acquisition  Manager.  The  two  basic  types  of  scanners  are 
page  scanners  and  large-format  scanners. 

Page  scanners  are  designed  to  be  implemented  with  text  or  graphics  up  to  8.5  by  11 
inches.  When  scanning  images  for  documents  that  are  currentiy  being  created  or 
updated,  a  single-page  scanner  should  work  well.  Features  for  a  single-page  scanner 
Include  quality  of  scan  and  moderate  speed.  Sheet-fed  scanrwrs  are  generally  used  to 
archive  large  amounts  of  paper  data.  The  features  required  are  speed  of  scan  and 
moderate  resolution. 

Large-format  scanners  are  used  to  generate  raster  images  from  paper  drawings  up  to 
60  inches  wide  with  an  unlimited  length.  The  scanners  are  monochrome/gray  scale 
and  are  a  single-sheet  feed  operatioa  in  recent  years,  the  speed  and  cost  have  been 
significantly  reduced  while  quality  has  been  enhanced.  Large-format  scanners  can 
provide  a  means  of  converting  old.  deteriorating  paper  drawings  into  an  electronic  form 
that  can  be  edited  and  restored,  if  required.  Al^ugh  the  cost  has  been  reduced 
significantly,  a  large-format  scanner  is  a  msjor  investment  and  is  usually  purchased  by 
the  software  support  activity  as  a  shared  resource. 

2J2.  Software  Considerations 

The  Acquisition  Manager  must  consider  how  a  specific  software  application  fits  into  the 
complete  data  process.  Configuration  management  software  may  be  needed  to  control 
the  access  and  revision  of  digital  data  files  as  well  as  the  specific  application  software. 
Software  applications  available  through  Navy  infrastructure  modernization  programs 
(see  Appendix  C)  should  be  considered  before  different  software  applications  are 
examined.  Another  important  question  is  whether  the  software  import  and  export  files 
are  in  a  CALS  format  such  as  MIL-D-28000  IGES  and  MIL-M-28001  SGML  This  will 
ensure  the  data  will  be  accessible  by  other  users. 

3,2.1  Data  Formats 

Digital  data  deliverables  available  in  the  CALS  environment  are  extensive.  Each 
Navy/Marine  Corps  Acquisition  Manager  must  evaluate  the  need  to  determine  which 
format  is  appropriate  at  each  stage  of  a  specific  program.  The  final  deliverables  must 
be  in  a  standard  CALS  format  while  preliminary  digital  data  may  be  in  a  format  that  is 
agreeable  to  the  Acquisition  Manager  and  the  contractor.  Commercial  word 
processing  software  with  the  capability  of  text  attribute,  style  sheets,  and  imbedded 
graphics  may  be  used  to  view  and  annotate  preliminary  TMs.  A  list  of  various  digital 
data  formats  is  shown  in  table  2. 

The  Acquisition  Manager  must  consider  who  is  going  to  use  the  data  in  the  fleet  and 
ensure  that  the  infrastructure  matches  each  user's  requirements  and  the  function  of  the 
requirements. 
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TABLE  2.  Standard  Digital  Data  Formats 


Standard  Digital  Data  Formats: _ 

MiL-D-28000  IGES  /CALS _ 

MIL-M-2e001  SGML /CALS _ 

MIL’R-28002  Raster  graphics  /CALS _ 

MIL-D-28003  CGM  for  illustration  data  /CALS _ 

Formatted  ASCII  text _ 

Page  Description  Language  POSTSCRIPT _ 

VHSIC  Hardware  Desaiption  Language  (VHDL)  /BBS 
Electronic  Design  Interchange  Format  (EDIR  /BBS 

IPC-D-3S0/BBS _ 

Native  CAD  format 


The  required  infrastructure  wiU  vary  depending  on  the  data  use  and  the  data  format. 
Formats,  such  as  MIL-R>28002  Raster,  will  require  a  Ngher  resolution  monitor  but  less 
processing  capability  to  view  and  modify  compared  to  a  solid-model-based  CAD 
system.  Raster  and  MIL-D-28000  IGES  data  formats  generally  necessitate  isrger  disk 
memory.  Some  data  functions  canriot  be  performed  on  all  digital  data  formats. 

Z2.S.  Operating  System  Compatibility 

The  first  consideration  is  which  operating  systems  the  program  uses.  The  operating 
system  variations  are  desaibed  in  3.1.2.  A  software  application  that  supports  both  disk 
operating  system  (DOS)  for  the  PCs  and  UNIX  for  the  RISC-based  workstations  will 
allow  greater  flexibility  than  a  program  tied  to  a  single  operating  system.  This  is 
especially  true  when  business  and  engineering  personnel  need  to  review  the  digital 
data  Most  business  applications  operate  on  a  PC  while  most  engineering  applications 
operate  on  RISC-based  workstation. 

X-window  emulation  software  may  solve  some  problems.  The  current  generation  of  X- 
window  emulation  programs  are  quite  robust  and  can  be  used  to  allow  PC  users  access 
to  UNIX  X-window  software  from  a  PC.  The  PC  emulation  packages  for  RISC-based 
workstations  are  not  as  sophisticated  as  the  X-window  emulation  programs. 
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3^  Application  Packagos 
Genorai  types  of  packages 


TABLE  3.  General  Types  of  Application  Packages 


CapabiiMoe 

Examplea 

Word  Processing 

Creating  Text-Based  Documents 

Docianents 

Spread  Sheet 

Calculations 

Data  Manipulations 

Chart  and  Graphs 

Finandal  Reports 
Engineering  Cai^lations 

Data  Reports 

Desktop  Publishing 

Advanced  Text  and  Graphics 
Integrated  Documents 

Advanced  Docunents  and 
Publications 

Mathematics 

Symbolic  Calculations 
Advanced  Calcuiations 

2-D,  3-D  Plots 

Engineering  Calculations 
Technical  Reports 

Terminal  Emulation 

Emulates  Specific  Terminals 
for  PCs 

X-Window  Emulator)  on  a  PC 

MCAD 

3-D  Solid  Modeling 
Mechanical  Drawing 

Weapon  System  Models 

Ship  Drawings 

Schematic  Capture 

Bectricai  Schematic 

Logic  Checking 

Wiring  Diagrams 

Avionics  System  Designs 

Printed  Wiring  Board 
(PWB)  Layout 

PWB  Layout 

PWB  Manufacturing  Data 

Computer  Aided  Manufacturing 

Finite  Bement 
Analysis 

Structural  Simulation 
Vibration  Simulation 

Thermal  Simulation 

Flight  Safety  Checks 

Cooling  Systems  Evaluations 

Dynamic  Simulation 

Mechanism  Simulation 
Dynamic  System  Simulation 

Bomb  Rack  Mechanism 
Evaluations 

Vehicle  Characteristic  Simulations 

Electrical  Simulation 

VHDL 

Analog  Simulation 

ASIC  Simulation 

Computer  Aided  Ertgineering  | 

3^4  Software  Licensing 

The  type  of  software  licensing  available  can  affect  the  total  cost  to  implement  a 
software  system.  The  four  types  of  software  licensing  that  are  prevalent  today  are 
single-user  license,  single-computer  license,  network  license,  and  a  site  license.  Each 
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licensing  option  has  a  proper  use  and  can  greatly  affect  the  total  life-cycle  costs 
associated  with  the  software  procurement 


A  single-user  license  allows  the  software  to  be  loaded  on  one  computer,  and  one 
person  has  access  to  the  program  at  a  time.  Most  PC  software  programs  are  licensed 
to  a  single  user.  A  single-computer  license  is  licensed  for  a  specie  computer,  and  the 
vendor  may  charge  to  move  the  license  to  a  different  computer.  This  type  of  license 
can  allow  either  a  single  user  or  multiple  users  access  to  the  program.  The  multiple- 
user  option  is  generally  used  when  the  software  is  operating  on  a  mainframe  computer 
or  network  server. 

A  network  license  will  allow  a  specific  number  of  simultaneous  users,  who  share  a 
common  network,  access  to  the  program.  Single-computer  and  network  licenses  are 
usually  offered  on  software  available  on  UNIX  workstations.  These  licenses  can 
reduce  the  total  cost  of  supplying  the  needed  software  for  all  of  the  users  of  an 
acquisition  program. 

A  site  license  allows  the  software  to  be  used  on  any  computer  at  a  particular  location. 
3.3  Telecommunications 

The  standard  equipment  required  for  telecommunications  is  a  modem.  The  modem  is 
used  to  link  two  or  more  computer  systems  via  a  phone  line.  Normal  uses  could 
IrKlude  connection  to  larger  computer  systems  via  a  terminal  emulation  program, 
connection  to  a  remote  site  to  send/receive  files,  or  to  access  CITIS.  A  more 
specialized  modem  that  has  become  readily  available  is  a  modem  capable  of  sending 
and  receiving  FAX  data  as  well  as  the  standard  CCITT  (Committee  for  International 
Telephone  and  Telegraph)  information. 

The  speed  requirement  of  the  modem  is  direcUy  related  to  the  size  of  the  data  files  that 
will  be  transferred  and  frequency  that  the  modem  will  be  used.  If  data  is  only  to  be 
accessed  and  viewed  remotely  using  a  terminal  emulation  program,  then  a  9,600  baud 
(character  per  second)  modem  is  probably  acceptable.  However,  if  there  is  a 
requirement  to  send/receive  large  data  files,  a  faster  modem  with  built-in  data 
compression  is  required.  Before  purchasing  a  modem,  the  Acquisition  Manager  should 
assure  compatibility  with  the  remote  location. 

3.3.1  Network  Protocols 

Network  protocols  are  essentially  the  software  standards  that  enable  users  to 
communicate  over  LANs  or  WANs.  There  are  several  types  of  network  protocols  that 
are  acceptable  in  the  CALS  community.  Factors  to  consider  when  choosing  the  type  of 
network  protocol  needed  include  current  facility  LAN/WAN  compatibility,  interface 
requirements,  data  to  be  transferred,  and  distance  of  network.  The  following  are 
common  protocols  and  their  capabilities. 

•  GOSIP:  The  Government  Open  Systems  Interconnection  Profile  (GOSIP)  is  the 
Government  standard  for  networking  protocols,  its  function  is  to  provide 
interoperability  among  different  equipment  manufacturers  (FIPS  PUB  146-1). 
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TCP/IP:  This  is  the  general  protocol  (IEEE  802.3)  for  most  engineering 
workstations  and  servers.  It  allows  UNIX  computers  to  conrmct  to  each  other  for 
remote  login  with  riogin  and  rsh  UNIX  commands.  It  also  allows  a  PC  with  X- 
windowing  software  to  establish  an  X-window  session  on  a  UNIX  server. 


LAN 


A  LAN  is  required  when  there  are  several  users  who  need  to  share  data,  application 
software,  and  equipment  The  LAN  network  devices  are  commonly  printers,  disk 
drives,  modems,  and  other  Management  Information  System  (MIS)  equipment  As  the 
name  LAN  suggests,  this  type  of  network  is  contained  within  a  small  area  (usually 
within  the  same  building  or  floor). 


FIGURE  4.  Example  of  Basic  LAN  Layout 


LANs  are  based  on  the  needs  of  the  user.  Some  LANs  may  only  .teed  to  be  connected 
to  share  resources  such  as  modems  or  printers.  Another  LAN  function  could  be  used 
for  configuration  management  of  large  CALS  databases. 


A  common  need  for  organizations  is  to  transfer  data  from  one  LAN  to  another  or  to 
connect  to  a  large  mainframe  computer.  These  functions  can  be  achieved  with  what  is 
commonly  referred  to  as  a  bridge. 


15 


3J.2.1  LAN  Application  Software 

NFS  (may  come  with  UNIX  operating  system)  allows  network  file  transfer  and  a  file 
server^  storage  device  to  become  a  loc^  device  trarvsparent  to  the  user  avidiabie  on 
the  PC. 

ZJi3  WAN 

A  WAN  is  required  when  there  are  several  users  who  need  to  share  data  or  equipment 
over  a  large  area  (usually  many  miles).  A  WAN  should  only  be  corwidered  If  there  is  a 
need  to  transfer  large  amounts  of  data  for  long  periods  of  time.  If  occasional  or  limited 
use  of  access  to  remote  data  or  equipment  is  needed,  then  a  modem  will  suffice. 

There  are  several  Goverrunent  WANs  that  can  be  accessed  by  the  CALS  community. 
These  networks  include  NAVNET,  DSN.  and  Internet 

3.4  Data  Processes 

The  Navy  Acquisition  Manager  needs  to  determine  what  digital  data  functions  are 
required  and  who  is  the  data  user.  The  infrastructure  may  vary  for  each  use  of  the 
data,  if  the  hardware,  softvrare,  and  network  cost  are  to  be  minimized.  Gerterally, 
certain  data  functions  are  performed  with  a  specific  format  Conversion  software  may 
need  to  be  procured  to  ensure  that  the  format  of  the  data  is  also  compatible  with  the 
end  user's  requirements.  The  user  functions  are  divided  in  the  following  areas. 

•  View;  Acceptance,  verification,  and  review  of  acquired  digital  data  sets. 

•  Comment/Annotate:  Annotate  or  highlight  for  future  reference,  or  make 
annotations  and  comments  without  the  ability  to  change  the  original  file.  The 
annotations  are  associated  with  a  specific  item  or  location  within  a  document 

•  Update/  Maintain:  Update  and  modification  of  digital  data 

•  Process/Transform;  Categorize.  exU’act,  cross-reference,  and  modify  the 
format,  composition,  and  structure  of  the  data  into  another  usable  form. 

•  Archive:  Storage  of  the  accepted  data  into  a  repository,  managed  by  a  central 
index  or  locator. 
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4.0  INFRASTRUCTURE  REQUIREMENTS  FOR  PROCESSING  DIGITAL  DATA 


4.1  Introduction 

The  following  section  contains  information  to  aid  the  Navy/Marine  Corps  Acquisition 
Manager  in  determining  the  infrastructure  needed  to  process  digital  data.  Digital  data 
includes  the  TMs,  TOP,  and  the  LSAR.  TMs  are  any  technical  publication  or  other  form 
of  documentation  used  to  install,  operate,  maintain,  test,  repair,  and  overhaul 
equipment  or  to  provide  logistic  support  for  ships,  aircraft,  defense  systems,  or  defense 
materiel.  The  TDP  contains  the  information  necessary  to  describe  a  defense  system 
and  its  componerrts  in  terms  of  design,  engirteering,  manufacturing,  artd  logistic 
support  LSARs  contain  the  information  necessary  to  describe  a  defertse  system  and 
its  components  in  terms  of  design,  engineering,  manufacturing,  and  logistic  support. 

The  current  user  infrastructure,  as  well  as  any  appKcable  Navy  or  Department  of 
Defense  (DoD)  modernization  programs,  must  be  considered  in  any  decision  to  procure 
rtew  computer  equipment  or  software.  Navy  Acquisition  Managers  should  give 
preference  to  the  Navy^  infrastructure  modernization  programs  over  general  DoD 
infrastructure  programs  and  gerteral  procurements. 

4.2  Infrastructure  Modernization  Programs  for  Digital  Data 

The  Navy  infrastructure  modernization  programs  for  digital  data  are  designed  to  be 
implemented  at  the  support  activity  and  are  typically  funded  through  the  DBOF.  Due  to 
the  cost  of  the  equipment  and  software  required  for  the  Navy  Infrastructure 
Modernization  Programs,  these  systems  are  made  available  to  the  Acquisition  Manager 
as  a  shared  resource.  The  Acquisition  Manager  should  be  familiar  virith  the  systems 
available  and  the  system  requirements  needed  to  facilitate  compatibility  between  the 
software  support  activity  and  the  local  Acquisition  Manager's  digi^  data  infrastructure. 
The  following  paragraphs  provide  an  overview  of  what  infrastructure  modernization 
programs  are  available.  See  Appendix  C  for  greater  detail  on  infrastructure 
modernization  programs. 

4.2.1  Navy  infrastructure  Modernization  Programs  for  TMs 

The  following  Navy  infrastructure  modernization  programs  are  designed  to  aid  in  the 
creation,  management,  and  use  of  digital  TMs. 

•  Automated  Document  Management  and  PublisNng  System  (ADMAPS): 
ADMAPS  is  a  contract  vehicle  to  provide  a  CALS-compliant  (ASCII/SGML) 
publishing  system  for  the  acceptance,  verification,  creation,  and  updating  of 
TMs  and  other  Navy  documentation.  ^MAPS  serves  as  a  front-end  processor 
to  transport  TMs  to  TMPODS. 

•  Technical  Manuals  Publish-On-Demand  System  (TMPODS);  TMPODS  stores 
Navy  TMs  in  CALS-compliant  digital  format  and  provides  for  the  production  and 
delivery  on  an  as-needed  basis.  TMPODS  stores  the  manuals  in  raster  format 
with  TM  indexing,  and  SGML  TMs  are  processed  through  ADMAPS,  which  will 
support  lETMS.  It  includes  the  capability  to  print  TMs  ii  ■  book  form  or  to  produce 
in  digital  format  on  optical  media 
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•  Advanced  TechnicaJ  Information  System  (ATiS);  AXIS  is  a  presentation  system 
designed  to  place  current  and  accurate  digital  technical  data  into  user  hands. 
ATIS  allows  engineers  to  access  technical  documentation,  retrieve  it  from  a 
digital  repository  such  as  JEOMICS  and  TMPOOS,  and  create  technical 
information  files  containing  repair/planning  data 

Navy  Infrastructure  Modernization  Programs  for  TDPs 

The  Navy  infrastructure  modernization  programs  designed  to  aid  in  the  creation, 
management  and  use  of  digital  TOPs  are; 

•  Computer  Aided  Design  (Second  Acquisition)  (CA02):  The  CAO-2  program  is 
intended  to  meet  the  Navy's  need  to  continuously  improve  its  engineering 
design,  manufacturing,  arxi  maintenance  capabilities. 

•  Joint  Engineering  Data  Management  Information  and  Control  System 
(JEDMICS):  JEDMiCS  is  the  joint  services  “digital  warehouse*  for  engineering 
drawings  and  related  technical  data,  it  will  accept  drawings  and  related  data  in 
standard  digital  form  or  will  digitize  drawings  and  data  from  hard  copy.  The 
system  indexes,  stores,  and  retrieves  the  data  digitally  and  can  distribute  it  in 
several  ways  irx:luding  paper,  disk,  and  CD-ROM. 

•  Navy  Engineering  Drawing  Asset  Locator  System  (NEDALS);  NEDALS  is  an 
automated  indexing  and  ordering  system  for  ail  NAVSEA,  NAVAIR,  SPAWAR, 
and  SPCC  engineering  drawings. 

•  ATIS:  Refer  to  4.2.1. 

•  Advanced  Industrial  Management  (AIM);  AIM  is  a  major  Naval  shipyard  initiative 
to  change  the  functional  process  for  ship  maintenance  and  repair  management 
by  improving  the  shipyard's  ability  to  plan,  estimate,  and  schedule  work.  AIM 
consists  of  the  ATIS  module  and  Advanced  Planning  and  Packaging  Support 
(APPS).  The  APPS  module  will  create  work  packages  from  the  technical 
information  in  ATiS.  This  information  is  used  to  package  and  manage  shipyard 
work  by  work-task  planning,  packaging,  schedule  control,  status  tracking,  work 
certification,  material  support,  and  documentation  distribution. 

4.2.3  Navy  Infrastructure  Modernization  Programs  for  Integrated  Logistic 
Support  (ILS)/Logistic  Support  Analysis  Record  LSAR 

The  Navy  infrastructure  modernization  programs  designed  to  aid  in  the  creation, 
management,  and  use  of  digital  LSARs  are: 

•  Material  Readiness  Support  Activity  (MRSA)  Certified  LSAR  Software: 
There  are  several  commercially  available  LSAR  software  packages.  These 
packages  can  generate  electronic  LSAR  as  well  as  reports  in  ILS  reports. 
The  Acquisition  Manager  should  consider  purchasing  multi-user  software 
licenses  when  there  will  be  muHipie  users  of  the  LSAR  data  For  a  complete 
listing  of  MRSA  certified  software  packages,  please  contact  MRSA  directly. 

•  AIM:  Refer  to  4.2.2. 
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4J2.4  DoO  Infrastructure  Modernization  Programs  for  Digital  Data 

Joint  Services/Defense  Logistic  Agency  Computer-aided  Acquisition  and  Logistic 
Support  (JCALS);  The  JCALS  program  is  the  DoO  joint  services  initiative  to  modernize 
the  processes  for  the  capture,  storage,  and  processing  of  logistic  technical  information 
required  for  weapons  systems  acquisition,  design,  manufacture,  and  support  Logistic 
technical  information  will  be  linked  through  communication  networks  to  ^iitate  data 
sharing  by  authorized  users.  JCALS  will  allow  authorized  users  throughout  DoO  to 
access  on-line  electronic  information  resident  in  a  JCALS  integrated  weapons  system 
database. 

4  J  Hardware  Requirements  for  Procaaaing  Digital  Data 
4^.1  Hardware  Requirements  for  Processing  TMs 

The  hardware  requirements  for  processing  TMs  are  dependent  on  the  specific 
requirements  of  the  user.  Table  4  displays  the  specific  requirernems. 

The  archive  requirement  for  processing  TMs  is  provided  by  the  TMPODS  system. 
However,  if  the  Acquisition  Manager  chooses  to  retain  a  separate  archive  master,  the 
suggested  system  hardware  on  table  4  provides  TM  archive  capability. 

The  view  only  function  requires  the  basic  equipment  to  reference  TMs.  The  equipment 
can  be  as  simple  as  a  machine  that  can  display  ASCII  characters  or  as  complex  as 
readirtg  CO  ROM  over  a  network.  The  hardware  in  table  4  displays  the  equipment 
required  for  accessing  TMs  from  a  CO  ROM. 

The  commenVannotate  function  for  processing  TMs  is  used  primarily  during  the  review 
process  prior  to  and  during  validatioa  The  comment/annotate  function  is  still  present 
on  systems  such  as  Interactive  Bectronic  Technical  Manuals  (lETMs).  This  is  to  allow 
technical  personnel  the  capability  to  include  additional  information,  if  required.  To 
accomplish  this  task,  there  must  be  a  iirtk  between  CO  ROM  data  and  additional 
information  stored  remotely.  If  there  is  no  direct  link  between  the  CD  and  the  additional 
information,  then  there  is  no  requirement  to  supply  CD  ROM  drives  with  a  system 
required  to  comment/annotate  TMs. 

The  hardware  requirements  for  updating  and  maintaining  TMs  include  the  capability  to 
work  with  tagged  SGML  documents.  The  system  requirements  for  using  an  SGML 
editor  can  be  found  in  table  4.  Specific  requirements,  including  CD  ROM,  scanners, 
and  WORM  drives,  should  be  addressed  on  a  case-by-case  basis  depending  on  the 
type  and  amount  of  data  being  processed. 

The  hardware  requirements  for  extracting,  processing,  and  transforming  TM  data 
depend  on  the  data  being  generated.  The  TM  can  be  generated  in  a  commercial  editor 
and  translated  into  SGML  at  a  later  time.  This  can  reduce  the  infrastructure 
requirements  if  there  is  a  basic  infrastructure  already  in  place,  if  the  requirement  is  to 
trar^form  an  approved  TM  into  an  lETMS,  then  the  hardware  should  reflect  standard 
lETMS  equipment 
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TABLE  4.  Matrix  of  Infrastructure  Requirements 
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4.3^  Hardware  Requirements  for  Processing  TDPs 

Two  decisions  that  affect  the  hardware  requirements  are  whether  the  final  engineering 
drawings  will  be  stored  in  the  native  CAO  files  or  an  equivalent  vector  format  versus 
raster  and  whether  the  engineers  will  be  performing  simulation.  Raster  data  does  not 
allow  the  ability  to  utilize  the  data  for  engineering  analysis;  thus,  the  processing 
requirement  to  work  with  only  raster  data  can  be  significantly  less  than  with  processable 
vector  format,  such  as  Initial  Graphics  Exchange  Specification  (IGES)  or  VHDL 

Processing  TDPs  with  raster  is  limited  to  changes  that  would  be  accomplished  on  a 
paper  or  2-0  drawing.  This  type  of  processing  could  make  basic  changes  relatively 
quickly  and  easily.  However,  modeling  and  simulation  are  best  suited  for  3-D  vector 
data 

The  hardware  requirements  differ  among  the  disciplines  of  engineering  required  to  be 
processed.  There  are  some  basic  commerdai  IGES  drawing  packages  that  can 
produce  3-D  models  on  an  80486  computer.  If  the  Acquisition  Manager  plaits  to 
simulate  the  stresses  of  a  mechanical  part  or  ttte  multilayer  printed  circuit  board  (PCB) 
layout,  a  RISC-based  workstation  should  be  considered.  In  addition  to  the  basic 
workstation,  the  Acquisition  Manager  should  address  the  procurement  of  the  following 
equipment 

•  Database  Server  (required  for  large,  drawing  databases) 

•  MIL-STD'1840  ta^  drive  (standard  for  large,  data  delivery) 

•  Other  media  drives,  including  DAT.  cartridge  tape,  and  QIC  (provide  large 
storage  capacity) 

•  PostScript  printer  (required  for  A  size  drawing  and  documerrtation) 

•  A  to  D  size  electrostatic  plotter  (large  volume  of  drawings  or  for  raster  drawings) 

•  A  to  D  size  pen  plotter  (low  volume  vector  drawings) 
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Hardwar*  Requiraments  for  Processing  iLS/LSAR 


The  specific  hardware  requirement  for  processing  ILSA^AR  is  directly  dependent  on 
the  software  requirements.  Several  configurations  can  be  made  depending  on  the 
number  of  users  who  need  to  access  LSAR  data.  With  multiple  users  sharing  data,  it  is 
recommended  that  a  LAN-based  LSAR  system  be  irtstailed.  However,  if  the  r>eed  is  for 
a  single  user  only,  refer  to  table  4  for  a  guideline  of  the  equipment  required. 

4.4  Software  Requirements  For  Processing  Digital  Data 

The  software  requirements  for  processirtg  digital  data  wilt  be  dependent  on  how  the 
digital  data  is  received:  on  magnetic,  via  LAN/WAN  or  modem,  or  other  data  transfer 
means.  All  of  these  options  will  carry  with  them  specific  software  needs  and  operating 
system  requirements.  The  Acquisition  Manager  should  procure  systems  that  are 
compatible  with  not  only  end  user  output  requirements  but  also  with  both  known  and 
possible  future  digital  data  sources. 

4.4.1  Software  Requirements  For  Processing  TMs 

Once  the  program  logistics  support  agent  has  determined  the  need  for  a  TM  and  the 
TM  manager  agent  has  completed  the  Technical  Manuals  Contract  Requirements 
(TMCRs),  the  typical  TM  creation  process  consists  of  authoring,  reviewing,  updating, 
and  inspecting  the  technical  manual  or  publication.  Each  program  can  accomplish 
these  tasks  by  various  methods. 

The  first  decision  the  Navy/Marine  Corps  Acquisition  Manager  must  decide  is  whether 
the  TM  will  be  an  illustrated  text  data  file  technical  manual  or  an  lETM.  This  decision, 
along  with  the  data  use  and  the  data  format,  will  determine  the  specific  infrastructure 
individuals  involved  will  require  in  the  creation,  management,  and  use  of  a  TM. 

4.4.1 .1  Software  Requirements  For  Creating  SGML  Format  TMs 

The  preliminary  TM  may  be  authored  In  a  variety  of  software  programs.  Commercial 
word  processing  software,  desktop  publishing  software,  or  an  SGML  editor  all  have 
ability  to  author  technical  documents  with  imbedded  tables  and  figures.  Therefore,  the 
Acquisition  Manager  must  ensure  that  file  TM  reviewers  have  software  compatible  with 
the  contractor's  TM-authoring  software  unless  the  contractor  is  providing  the  view  and 
annotate  with  a  CITiS.  The  TM  reviewer  must  be  able  to  view  and  annotate  the  TM  file 
rather  than  edit  the  existing  file.  Once  the  preliminary  version  is  complete,  commercial 
software  is  available  to  convert  a  word  processing  or  desktop  publishing  document  into 
a  MIL'M-28001  SGML  format  file.  These  programs  try  to  add  all  the  appropriate  tags  to 
the  SGML  text  file. 

If  the  preliminary  TM  is  in  SGML  format,  several  options  exist  to  allow  users  to  view 
and  annotate  the  manual.  Low-cost  SGML  document  editors  are  available  for  PCs  and 
UNIX  workstations.  POL  viewers  and  annotator  translators  can  be  purchased  to 
convert  the  entire  SGML  file  into  raster  format,  word  processing  file  formats,  and 
desktop  publishing  file  formats. 
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Network  software  licensing  and  data  translators  can  minimize  the  cost  of  procuring  the 
required  software  products.  Since  most  users  irtvolved  in  the  review  of  a  TM  will  not  be 
needing  an  SGML  editor  all  the  time,  a  single  network  license  may  provide  five  to  ten 
users  access  to  the  software.  As  a  final  option,  translators  can  also  be  purchased  to 
convert  the  document  format  into  a  format  compatible  with  their  existing  software.  Data 
files  can  be  translated  among  SGML  and  raster  format,  word  processing  file  formats, 
and  desktop  publishing  file  formats.  A  complete  list  of  possible  translations  among 
data  formats  is  listed  in  table  2. 

4.4.1 .2  Software  Requirements  For  Creating  lETMs 

The  prelimirwy  lETM  may  be  developed  in  a  commercial  word  processing  software  or 
SGML  editor.  Once  the  preliminary  version  s  complete,  the  data  must  be  converted 
such  that  a  Hypertext  system  can  retrieve  the  data  and  display  the  information 
requested.  UEMs  should  be  developed  on  systems  that  are  capable  of  executing 
complex  grapNcai  user  interface  processes  without  delay. 

4.4.1 .3  Software  Requirements  For  Managing  TMs 

Once  the  final  reproducible  copy  of  the  TM  is  accepted,  the  cognizant  life-cycle 
maintenar)ce  activity  is  responsible  for  the  corrfiguration  managemerrt  of  the  document 
To  property  implement  configuration  management,  the  following  software  packages 
should  be  available  to  the  configuration  manager. 

•  SGML  editor 

•  DTD  editor 

•  Illustrator  editor  for  vector  and  raster 

•  Configuration  management  database 

4.4. 1.4  Software  Requirements  For  Using  TMs 

The  software  requirements  for  using  TMs  are  based  on  the  user's  receiving  electronic 
data  containing  the  TM  and  having  the  needed  software  to  utilize  the  TM.  Depending 
on  the  format  that  the  TM  was  delivered  in,  the  end  user  couid  require  any  part  of  the 
following  software  to  utilize  the  TM. 

•  PDL  viewer  and  annotator 

•  SGML  parser  to  extract, 

•  Illustrator  editor  for  vector  and  raster 

•  Database  query  application 

4.4.2  Software  Requirements  For  Processing  IDPs 

The  first  decision  that  affects  the  software  requirements  is  whether  the  final 
engineering  drawings  will  be  stored  in  the  native  CAD  files  or  an  equivalent  vector 
format  versus  raster.  Raster  data  does  not  allow  the  ability  to  utilize  the  data  for 
engineering  analysis;  thus,  the  processing  requirement  to  work  with  only  raster  data 
can  be  significantly  less  than  with  processable  vector  format,  such  as  IGES  or  VHDL 
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4.4^.1  Software  Requirements  For  Creating  TDPs 

The  software  requirements  for  creating  TDPs  can  be  in  several  formats.  The  specific 
format  used  depends  on  the  type  of  data  being  generated  and  the  way  the  data  will  be 
managed  throughout  its  life  cycle.  The  following  formats  may  be  used. 

•  Native  CAO 

•  CAD-2 

•  IGES  view 

•  FEM  (VHDL  simulation) 

4.4.2^  Software  Requirements  For  Managing  TDPs 

Managing  the  TOP  after  its  distribution  to  the  fleet  will  entail  all  of  the  same  software 
requirements  needed  during  its  creation.  The  following  list  of  software  applications  may 
be  required  to  meet  these  needs. 

•  CAD-2 

•  Ruid  flow  analysis 

•  PWB  layout 

•  SPICE  simulator 

•  VHDL  simulator 

•  PLD  software 

•  Hybrid/Appiication  Specific  Integrated  Circuit  (ASIC)  software 

•  Configuration  management 

•  Relational  database 

4.42.3  Software  Requirements  For  Using  TDPs 

The  requirements  for  using  TDPs  are  limited  by  the  fact  that  users  will  not  edit  or 
change  the  content  of  the  TOP.  Therefore,  only  the  software  necessary  to  view  and 
print  the  TDP  data  will  be  required.  This  will  then  depend  on  the  type  of  TDP  being 
used  and  the  formats  in  which  it  was  distributed.  The  manager  will  have  to  determine 
what  TDP  formats  are  likely  to  be  encountered  and  develop  a  system  appropriate  to  the 
end  users'  requirements.  This  will  include  ail  or  part,  but  not  limited  to,  the  following 
programs. 

•  IGES  translators 

•  Configuration  management 

•  Relational  database 

•  CAD-2  -  PWB  layout 

4.4.3  Software  Requirements  For  Processing  LSARs 

The  Acquisition  Manager  will  be  required  to  assure  that  any  software  used  to  process 
LSAR  data  is  certified  by  MRSA  and  meets  MlL-STD-1388 
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43  Tvlacoimnunications  Requirsments  for  Procossing  Digital  Data 

The  telecommunications  requirements  for  processing  digitai  data  have  been  briefly 
diso^sed  in  section  3.  These  requirements  should  be  based  on  how  data  to  be 
shared  or  manipulated  and  what  current  telecommunications  infrastructure  is  available. 

Specifically,  the  Acquisition  Manager  should  determine  the  average  number  and  size  of 
data  transfers  to  determine  the  type  and  size  of  the  communication  systems  needed. 
Considerations  are  the  number  of  modems  or  outside  tines  being  supported,  baud  rate 
of  the  modem,  error  detection/correction  performance,  and  compatibility  to  data 
sources.  Will  the  telecommunications  system  be  installed  using  standard,  conditioned, 
trunk,  or  uninteruptable  lirtes,  or  will  fiber  optics  be  used,  if  available?  Once  the  data  is 
coming  into  the  fsteiUty,  how  and  where  wilt  it  be  stored,  and  will  other  outside  sources 
be  allowed  access?  All  these  factors  need  to  be  given  careful  consideration.  The  initial 
decisions  will  affect  the  current  operation  and  future  expansion  of  the  system. 
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5.0  CONTRACT  VEHiCLES  FOR  INFRASTRUCTURE  REQUIREMENTS 

There  are  many  options  an  Acquisition  Manager  can  invoke  \when  acquiring  digital 
infrastructure.  Depending  on  the  type  of  equipment  required,  the  Acquisition  Manager 
can  use  existing  Government  contracts  to  acquire  equipment.  It  is  important  that  the 
Acquisition  Manager  work  closely  with  their  local  ADP  or  FIPS  manager  when  making 
equipment  purchase  decisions.  The  ADP  or  FIPS  manager  is  cognizant  of  their 
facility's  current  technology  and  standards.  This  can  result  in  cost  saving  compared  to 
commercial  low  bid  or  GSA  pricing.  An  up-to-date  listing  of  the  US  Navy  and  DoD 
umbrella  contracts  can  be  found  on  NC  TAMS  LANT  on-line  Bulletin  Board  System 
(BBS).  Access  can  be  made,  initially,  to  view  current  contracts  as  well  as  contracts  in 
progress.  The  telephone  number  for  the  BBS,  OASYS  are  as  follows: 

(804)  445-1127 
(804)  445-1627 

The  communication  parameters  are  up  to  9600  BPS  with  8-1 -N  as  the  communication 
parameters. 

If  file  transfer  is  required,  please  contact  the  following  group  for  formal  access  upgrade: 

Commanding  Officer 
NCTAMS  LANT 
Code  N813.2 

9456  Fourth  Ave  Suite  200 
Attn:  File  Library  Upgrade 
Norfolk,  VA  2351 1-2199 


NOTE:  Local  ADP  authority  should  be  contacted  for  contract  vehicle  information. 


25 


APPENDIXES 


CALS  IN  THE  ACQUISITION  PROCESS 
Naval  Forcas  Parapactiva 

DoM  CM^ /WsquWtion  Wortilng  Graup 

This  Modtl  AppWM  lo  Mch  PfWM  of  tfi*  Dotonco 
Syttom  Acquiiition  Procot* 


OoOSOOOS 

(«Ng9 


APPENDIX  A 


ACRONYMS,  DEFINITIONS, 
AND  APPLICABLE  DOCUMENTS 


SECOND  EDITION 
30  Jun»  1093 


Prepared  by; 

CALS  Resource  and 
Implementation  Cooperative  (RIC) 


Prepared  for 

Navy  CALS  Acquisition/ 

Implementation  Group 


ACRONYMS 


A>1.0  Acronyms  used  in  the  desktop  guide. 


2- D 

3- D 

AOMAPS 

ADP 

AE 

AIM 

ALPS 

ANSI 

AP 

APPS 

ASCII 

ASIC 

ASME 

ATIS 

BCS 

CAC 

CAD/CAM/CAE 

CAD2 

CAE 

CALS 

CALS  RIC 

CALSIP 

CAM 

CASE 

ccnr 

CD 

CD-ROM 

CDI 

CDM 

CDNSWC 

CDR 

CDRL 

CE 

CEIO 

CFA 

CGM 

cms 

CIVR 

CUN 

CUP 

CMA 

COTS 

CPU 

CSAR 

CSL 

CSR 


2- Oimenslonal 

3- Dimensionai 

Automated  Document  Management  Infonmation  and  Control  System 
Automated  Data  Processing 
Age  Exploration 

Advanced  Industrial  Management 
Automated  Logistics  Publishing  System 
American  National  Standard  institute 
Acquisition  Plan 

Advanced  Planning  and  Packaging  Support 
American  Standards  Committee  for  Information 
Application-Specific  Integrated  Circuits 
American  Society  of  Mechanical  Engineers 
Advanced  Technical  Information  System 
Baseline  Comparison  System 
Contractor's  Approach  to  CALS 

Computer-Aided  DesigrV  Computer-Aided  Manufacturing/Computer- 
Aided  Engineering 

Computer-Aided  Design  (Second  Acquisition) 

Computer-Aided  Engirteering 
Computer-aided  Acquisition  and  Logistics  Support 
CALS  Resource  and  Implementation  Cooperative 
CALS  Implemernation  Ran 
Computer-Aided  Manufacturing 
Computer-Aided  Software  Engineering 
Consultative  Committee  for  Telephone  and  Telegraph 
Compact  Dist 

Compact  Disk  -  Read  Only  Memory 
Compact  Disk  Interactive 
Content  Data  Model 

Carderock  Division  of  the  Naval  Surface  Warfare  Center 

Criticai  Design  Review 

Contract  Data  Requiremwits  List 

Concurrent  Engineering 

CALS  Evaluation  and  Integration  Office 

Cognizant  Field  Activities 

Computer  Graphics  Metafile 

Contractor  Integrated  Technical  Information  Senrice 

Configuration  Item  Verification  Review 

Contract  Une  Item  Number 

Configuration  and  Logistics  Information  Program 

Configuration  Management  Agent 

Commercial  Off-the-Shetf 

Computer  Processing  Unit 

Configuration  Status  Accounting  Reports 

CALS  SGML  U'brary 

CALS  SGML  Registrar 
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CTi4 

CALS  Test  Network 

DAP 

Document  Application  Profile 

DAT 

Digital  Auto  Tape 

DB 

Database 

DBUF 

Defense  Business  Operating  Furvi 

DON 

Defense  Data  Network 

DEO 

Data  Bement  Definition 

DFARS 

Defense  Federal  Acquisition  Regulation  Supplement 

DID 

Data  Item  Description 

DLA 

Defense  Logistic  Agency 

OoO 

Department  of  Oefmse 

DoDO 

Department  of  Defense  Directive 

DoDI 

Department  of  Defense  Instruction 

Don 

Department  of  Navy 

DOS 

Disk  Operating  System 

DPI 

Dots  Per  Inch 

DSN 

Defense  Support  Network 

OSSSL 

Document  ^e  Semantics  and  Specification  Lar^uage 

DTD 

Document  Type  Definition 

DTMB 

David  Taylor  Model  Basin 

DTP 

DeskTop  Publishing 

DVI 

Digital  Video  Interactive 

ECP 

Engineering  Change  Proposal 

EDI 

Bectronic  Data  Interchange 

EDIF 

Bectronic  Data  Interchange  Format 

EDIFACT 

EDI  for  Administration,  Commerce,  and  Transportation 

EDMICS 

Engineering  Data  Management  Information  and  Control  System 

EDPODS 

Engineering  Drawing  Print-On-Demand  System 

EDS 

Bectronic  Display  System 

EIA 

Electronic  Industries  Association 

j  EUN 

Exhibit  Line  Item  Number 

EMD 

Engineering  and  Manufocturing  Development 

EPC 

Bectronic  Publishing  Committee 

FAR 

Federal  Acquisition  Regulation 

FAX 

Faximfle 

FCIM 

Flexible  Computer  Integrated  Manufacturing 

FCS 

Rnite  Coordinate  Space 

FIPS 

Federal  Information  Processing  Standard 

FMECA 

Failure  Modes  and  Effects  Criticality  Analysis 

FOSI 

Formatting  Output  Specification  Instance 

FPGA 

Reld-Programmabie  Gate  Arrays 

FRC 

Rnal  Reproducible  Copy 

G-byte 

Gigabyte 

GCA 

Graphic  Communication  Association 

GCO 

Government  Corrcept  of  Operations 

GR 

Government-Furnished  Information 

GIDEP 

Government-Industry  Data  Exchange  Program 

GOSIP 

Government  Open  System  Interconnection  Profile 

HW 

Hardware 

HW/SW 

Hardware/Software 

lAW 

In  Accordance  With 

2 

IEEE 

lETM 

IGES 

ILS 

ILSP 

IMIS 

IPC 

IPO 

ISAC 

ISQ 

ISO 

ISWG 

rro 

IWSOB 

JCALS 

JCMO 

JEDMICS 

LAN 

LOG 

LEM 

LLNL 

LLTIL 

LOGPARS 

LORA 

LRU 

LSA 

LSAP 

LSAR 

MACS 

MEDALS 

MIS 

MPT 

MRSA 

NAOC 

NATSF 

NAVAIR 

NAV  jET 

NAVSEA 

NAWC 

NO 

NCGA 

NDI 

NEOALS 

NFS 

NIDDESC 

NIFF 

NIMP 

NIST 

NPFC 

NPPS 

NTP 


Institute  of  Electrical  arxi  Electronic  Engineers 
Irrteractive  Bectronic  Technical  Manuals 
Initial  Graphics  Exchange  Specification 
Integrated  Logistics  Support 
integrated  Logistics  Su(^x>rt  Ran 
Integrated  Maintenance  Information  System 
Institute  for  Interconnecting  and  Packing 
IGES/POES  Organization 
Issues  Screening  and  Analysis  Committee 
Industry  Steering  Group 
international  Organization  for  Standardization 
Industry  Standards  Working  Group 
Instructions  To  Offers 
irrtegrated  Weapon  Systems  Data  Base 
Joint  CALS 

Joint  CALS  Management  Office 

Joint  Engineering  Data  Management  Information  and  Control  System 

Local  Area  Network 

Life  Cost  Cyde 

Logistic  Element  Managers 

Lawrence  Livermore  National  Laboratory 

Long  Lead  Time  Herns  List 

LOGistics  Planning  And  Requirements  Simpiificalion 

Level  of  Repair  Analysis 

Line  Replacement  Unit 

Logistic  Support  Analysis 

Logical  Support  Analysis  Ran 

Logistic  Support  Analysis  Record 

Mutually  Agreeable  Commerdai  Software 

DoD  Military  Engineering  Drawing  Asset  Locator  System 

Management  Information  System 

Manpower,  Personnel,  Training 

Material  Readiness  Support  Activity 

Naval  Air  Development  Center 

Naval  Aviation  Technical  Services  Fadlity 

Naval  Air  Systems  Command  Headquarters 

Navy  Network 

Naval  Sea  Systems  Command  Headquarters 
Naval  Air  Warfare  Center 
Numerical  Control 

National  Computer  Graphics  Association 
Non-Developmental  Items 
Navy  Engineering  Drawing  Asset  Locator  System 
Network  RIe  System 

Navy  Industry  Digital  Data  Exchange  Standards  Committee 

Navy  Image  RIe  Format 

Navy  Infrastructure  Modernization  Program 

National  Institute  of  Standards  and  Technology 

Naval  Publications  and  Forms  Center 

Navy  Publishing  and  Printing  Service 

Navy  Training  Plan 
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NWC 

NWS 

O&S 

OCR 

ODA 

ODIF 

OS 

OSD 

OSI 

PC 

PCA 

PCS 

POES 

POL 

PDR 

PHS&T 

PLD 

PMA 

PMS 

PMTC 

POSIX 

PWB 

QAPP 

QIC 

QSTR 

R&M 

RAMP 

RCM 

RDT&E 

RFD 

RFP 

RFQ 

RFW 

RISC 

ROM 

SAP 

SCLSiS 

SDIF 

SDR 

SE 

SEMP 

SERD 

SGML 

SIE 

SIG 

SNAP 

SOW 

QPA 

SPAWAR 

SPCC 

SPDL 


Naval  Weapons  Center 
Naval  Weapons  Station 
Operational  &  Suppt^ 

Optical  Cluracter  Recognition 

Open  Document  Architecture 

Office  Doovnent  interchar^iA  Format 

Output  Specification 

Office  of  the  Secretary  of  Defense 

Open  Systems  Interconrtection 

Personai  Computer 

Physical  Configuration  Audit 

Printed  Circuit  Board 

Product  Data  Exchange  using  STEP 

Page  Description  Data 

Preiiminary  Design  Review 

Packaging,  Handling,  Stowage,  &  Transportation 

Programmable  Logic  Design 

Portable  Maintenance  Aid 

Planned  Mairrtenance  System 

Pacific  Missile  Test  Center 

Portable  Operating  System  Interface 

Printed  Wiring  Board 

Quality  Assurance  Program  Plan 

Quarter  inch  Cartridge 

Quick  Short  Test  Reports 

Reliability  and  Maintainability 

Rapid  A^isition  of  Manufactured  Parts 

Reiiabiiity  Center  Maintenance 

Research,  Development  Test  and  Evaluation 

Request  for  Deviation 

Request  For  Proposal 

Request  for  Quotes 

Request  for  Waiver 

Reduced  Instruction  Set  Computing 

Read  Only  Memory 

Site  Activity  Plan 

Ship  Configuration « nr*  Logistic  Support  Information  Service 
SGML  Document  Interchange  Format 
System  or  Software  Design  Review 
Support  Equipment 

Sy^m  Engineering  Management  Plan 

Support  Equipment  Recommendation  Data 

Standard  Generalized  Markup  Language 

Special  Inspection  Equipment 

Special  Interest  Group 

Shipboard  Norttechnicai  ADP  Program 

Statement  of  Work 

Solicitation  Package  Automafc  - 

Space  &  Navy  Warfare  System  Command 

Ship  Parts  Control  Center 

Standard  Page  Description  Language 
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SQL 

SSAP 

STEP 

SW 

T&E 

TCP/IP 

TOP 

TEMP 

TI 

TIP 

TM 

TMCR 

TMM 

TMPODS 

TO 

TQM 

TTG 

UHOL 

UHSIC 

USAMC 

VASQ 

VHDL 

VHSIC 

WAN 

WBS 

WORM 

WRA 


Standard  Query  Language 
Site  Support  Activity  Plan 

Standard  for  the  Exchange  of  Product  Data  System 
Software 

Test  and  Evaluation 

Traremission  Control  Protocol/lntemet  Protocol 

Techr^eai  Data  Package 

Test  and  Evaluation  Master  Plan 

Technical  information 

Technicai  irtformation  RIe 

Technical  Manual 

TM  Contract  Requirement 

Technical  Manual  Manager 

TM  Print-OrvCemand  System 

Technical  Order 

Total  Quality  Management 

Tiling  Task  Group 

UHSIC  Hardware  Description  Language 
Ultra  High  Speed  Integrated  Circuits 
United  States  of  America  Marine  Corp. 

VHDL  Analysis  Standardzation  Group 
VHSIC  Hardware  Description  Language 
Very  High  Speed  Inte^ated  Circuit 
Wide  Area  Network 
Work  Breakdown  Structure 
Write  Once/Read  Many  times 
Weapon  Replaceable  Assembly 
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DERNmONS 


A-2.0  The  following  terminology  has  become  common  in  the  CALS  environment  in 
reference  to  data  deliverabies; 

AEGIS  is  the  combat  and  weapon  system  designed  for  use  on  the  US  Navy's  CG  47 
class  of  guided  missile  cruisers  and  the  DOG  51  dass  of  guided  missile  destroyers. 

A— oeiatod  Uet  is  a  tabulation  of  pertinent  information  related  to  an  item  depicted  on  a 
drawing . 

CGM  or  Computer  Graphics  Metafile  is  a  dgitai  data  file  containing  graphic  information 
in  a  file  format  compatible  with  most  other  graphic  systems. 

cms  (Contractor  Integrated  Technical  Information  Sendee)  is  a  contractor  developed 
service  which  provides  electronic  access  to  «id/or  deUvery  of  contractually  required 
Contract  Data  Requirements  List  (CDRL)  data  to  users.  CmS,  and  consequently  the 
contract  provisions  for  cmS,  does  not  indude  the  databases  to  witich  access  is 
granted,  or  the  database  process,  or  the  format  of  data  to  be  accessed  through  CITiS. 

Data  Presentation  Format  is  the  human  interpretation  of  data  such  as  text  layout, 
drawing  scale,  level  of  detail,  or  part  orientafioa 

Digital  Data  Format  is  the  Structure  of  the  dafo  on  the  physical  trartsfer  media  such  as 
IGES,  CGM,  SGML,  and  CCITT  Group  4  Raster. 

Digital  Data  is  data  represented  in  computer-generated,  binary  form. 

Document  applies  to  the  information  content  of  a  variety  of  different  printed  or  digital 
entities  that  contain  technical  information.  These  entities  may  be  technical  reports, 
analyses,  drawings,  specifications,  lists,  engineering  change  notices,  or  a  large  variety 
of  o^er  informatioa 

Drawing  Format  is  the  arrangement  and  organization  of  information  within  a  drawing. 
Tfus  includes  such  features  as  the  size  and  arrangement  of  blocks,  notes,  lists,  revision 
information,  and  use  of  optiortai  or  supplemental  blocks. 

EDI  (Bectronical  Data  Interdrange)  is  data  that  is  transmitted  or  communicated 
eiectronicaliy  according  to  established  rules  and  formats.  The  fomatted  data  may  be 
transmitted  from  originator  to  recipient  via  telecommunications  or  physically  transported 
on  electronic  storage  media 

End-oroduct  (End-item)  is  an  item,  either  an  individual  part  or  assembly,  in  its  final  or 
completed  state. 

Engineering  Data  are  engineering  documents  such  as  drawings,  associated  lists, 
accompanying  documents;  specifications,  and  standards,  or  other  information  prepared 
by  a  design  activity  and  relating  to  the  design,  manufacture,  procurement,  test,  or 
inspection  of  manufactured  Items. 


Engineering  Drawings  are  documents  that  disclose  directly  or  by  reference,  by  means 
of  graphic  and  textual  information,  the  physical  and  functional  end-product 
requirements  of  an  item.  Geometry,  material  requirements,  and  process  data,  along 
with  notational  explanations  pertaining  to  spedfic  functions  and  features  of  the 
depiction,  are  its  typical  contents. 

Hnal  Deitverables  are  any  item  or  items  specified  for  delivery  under  the  contract  to 
mark  the  completion  or  fulfillment  of  a  required  task  or  tasks. 

lEZM  or  Interactive  Electronic  Technical  Manual  is  a  computer-based  collection  of 
irrformation  needed  for  the  diagrtosis  and  maintenance  of  a  weapons  system,  optically 
arranged  and  formatted  for  irrteractive  presentation  to  the  end  user  on  an  electronic 
display  system. 

IGES  or  initial  Graphics  Exchange  Specification  is  a  neutral  file  format  for  the 
representation  and  transfer  of  product  definition  data  among  CAD/CAM  systems  and 
application  programs. 

ILS  or  integrated  Logistics  Support  is  a  disciplined,  unified,  and  iterative  approach  to 
the  management  and  technical  activities  necessary  to  integrate  support  considerations 
into  system  and  equipmertt  design;  develop  support  requirements  that  are  related 
consistently  to  readiness  objectives,  to  design,  and  to  each  other,  acquire  the  required 
support;  and  provide  the  required  support  during  the  operatioruy  phase  at  minimum 
cost 

ILS  Data  is  the  technical  information  to  support  the  ILS  management  process. 

Intallloeiit  or  Product  Data  adds  the  elements  of  life-cycle  support  to  the  elements 
found  in  product  definition  data.  [Ref.  Appendix  B,  Intelligent  (Product)  DaU^ 

Interim  Dellverablee  are  any  item  or  items  delivered  under  the  contract  that  are  not 
specifically  required  by  the  contract,  but  may  include  draft  forms  of  final  deliverables. 

Legacy  Data  is  technical  data  (ILS  Data,  engineering  drawings,  LSAR.  etc.)  that  was 
developed  and  archived  before  the  implementation  of  CALS  initiatives. 

or  Logistic  Support  Analysis  is  the  selective  application  of  scientific  and 
engineering  efforts  undertaken  during  the  acquisition  process,  as  part  of  the  systems 
engir^eering  process,  to  assist  in:  Causing  support  considerations  to  influence  design; 
defining  support  requirements  that  are  related  optimally  to  design  and  to  each  other; 
acquiring  the  required  support;  and  providing  the  required  support  during  the 
operational  phase  at  minimum  cost 

LSAR  or  LSA  Record  is  a  set  of  data  elements  formatted  in  either  fiat  file  or  relation 
table  that  is  comprised  of  ILS  technical  data  used  to  satisfy  support  acquisition. 

PDES/STEP  or  Product  Data  Exchange  using  STEP/Standard  for  the  Exchange  of 
Product  Model  Data  are  standards  and  specifications  under  development  for 
communicating  a  complete  product  model  with  sufficient  information  content  so  as  to 
be  interpretable  directly  by  advanced  CAD/CAM  applications  such  as  generative 
process  planning,  CAO-directed  inspection,  and  automatic  generation  and  verification 
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of  automated  manufacturing  data.  PDES  is  being  developed  as  a  national  standard, 
and  STEP  is  being  developed  as  the  international  counterpart.  STEP  is  the 
international  standards  effort  (officially  entitled  ISO  10303)  to  develop  a  neutral 
mechanism  capable  of  completely  representing  product  data  throughout  the  life  cycle  of 
the  product. 

Product  DefinWon  Data  denotes  the  totality  of  data  elements  required  to  completely 
define  a  product.  Product  definition  data  includes  geometry,  topology,  relationship, 
tolerances,  attributes,  and  features  necessary  to  completely  define  a  component  part  or 
an  assembly  of  parts  for  the  purpose  of  design,  analysis,  manufacture,  test,  and 
inspection. 

Product  Drawinos  are  engineering  drawing  that  provide  the  necessary  design, 
engineering,  manufacturing,  and  quality  support  infotmation  necessary  to  permit  a 
competent  manufacturer  to  produce  an  interchangeable  Item  that  duplicates  the 
ph)^ical  and  performance  characteristics  of  the  original  design  without  additional 
design  engineering  or  recourse  to  the  original  manufacturer. 

BflStSr  data  is  a  binary  representation  of  an  image.  There  are  two  types  of  raster 
tiled  and  untiled.  Untiled  raster  data  has  no  document  architecture  and  is  represented 
by  a  single  compressed  data  entity.  Tiled  raster  data  resembles  a  two>dimensiortal  grid 
witfi  each  tile  or  set  of  pixels  representing  a  portion  of  the  image. 

Technical  Data  Package  is  a  technical  description  of  an  item  consisting  of  ail 
applicable  technical  data  such  as  drawings  and  associated  lists,  specifications, 
standards,  performance  requirements,  quality  assurance  requirements,  and  packaging 
details  necessary  to  define  the  design  configuration  and  procedures  required  to  ensure 
item  performance. 

Technical  Manuals  are  any  technical  publication  or  other  form  of  documentation  used 
to  install,  operate,  maintain,  test,  repair,  or  overhaul  weapon  systems  and  support 
equipment  or  to  provide  logistic  support  of  ships,  aircraft,  weapon  systems,  or  defense 
material.  Technical  manual  information  may  be  presented  or  delivered  in  any  form 
including,  but  not  limited  to,  hard  copy,  audio  and  visual  displs^,  magnetic  tape,  discs, 
and  other  electronic  devices. 


mpR  or  Technical  Manual  Contract  Requirement  is  a  definitive  contractual  document 
th^  provides  the  complete  content  and  format  requirements  for  the  preparation  and 
delivery  of  one  or  more  technical  manuals  and  technical  manual  management  data 
items.  The  TMCR  consolidates  the  requirements  from  various  Government 
spedfications  and  standards  and  tailors  those  requirements  to  produce  a  technical 
manual  that  satisfies  specified  user  needs. 

Transfer  Media  Format  is  the  physical  form  of  the  data  deliverable  such  as  paper, 
microfilm,  magnetic  tape,  or  optical  disk. 

ypildfijlpn  is  the  comprehensive  testing  of  information,  data,  and  procedures  contained 
in  a  technical  manual.  This  testing  is  accomplished  by  review/comparison  of 
nonprocedural  material  against  up-to-date  source  data  and  by  actual  performance  of 
procedures  on  the  system  or  equipment  for  which  the  manual  was  written  by  the  TM 
preparing  activity. 


V»ctor  data  is  the  representation  of  an  image  as  a  sequence  of  line  segments.  Vector 
data  provides  geometrical  and  physicaJ  representation  of  objects  in  both  two  and  three 
dimensions. 

VerHicatlon  is  Government  testing  in  an  operational  erivb-onment  of  the  accuracy, 
adequacy,  and  suitability  for  use  of  a  tedmical  manual  prior  to  final  acceptance. 
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APPUCABLE  DOCUMENTS 


A-3.0  The  following  documents  contain  important  information  governing  ILS  or  LSA, 
TOPS,  and  technical  manuals.  They  also  contain  various  CALS  applications  concerning 
the  creation,  management  and  use  of  ILS  or  LSA.  TDPs,  and  technical  manuals.  This 
document  will  attempt  to  reference  the  docum^its  listed  below  where  applicable  and 
suggest  further  review  where  appropriate.  A  majority  of  the  information  contained  in 
the  following  discussions  has  come  directly  from  the  documents  being  discussed. 

A-3.1  DoDI  5000J2,  Defense  Acquisition  Management  Poiides  and  Procedures 
(Part  7,  Logistics  and  Other  Infrastructure) 

A<3.1.1  Scope  and  Purpose 

The  policies  and  procedures  in  this  directive  establish  the  basis  for  ensuring  that 
support  considerations  are  effectively  integrated  into  the  system  design.  It  ensures  that 
required  support  structure  elements  are  acquired  concurrently  with  the  system  so  that 
the  system  v^ll  be  supportable  and  supported  when  fielded. 

A-3.1 ,2  CALS  Intent 

The  integrated  nature  of  a  logistics  support  approach  such  as  this  touches  on  all 
aspects  of  system  planning,  design,  acquisition,  and  operation.  The  fact  that 
concurrent  and  iterative  development  of  the  logistics  aspects  is  desired  makes  the 
application  of  a  CALS  environment  more  desirable.  Much  ^  the  ten  aspects  of  logistics 
support  detailed  in  this  document  lends  itself  to  digital  acquisition  and  application. 

A-3.1 .3  Relevance 

All  of  the  data  generated  by  this  effort  can  be  considered  a  component  part  of  ILS  data. 
Included  in  this  part  are  Logistics  Support  Analysis  and  the  required  LSAR  effort  that 
goes  with  it  Emphasis  is  on  support  for  the  total  life  cycle  of  the  system  being  studied. 

A-32  MIL-HDBK-59,  CALS  Program  Implementation  Guide 

A-3J2.1  Scope  and  Purpose 

The  purpose  of  this  handbook  is  to  provide  detailed  application  information  and 
guidance  to  personnel  responsible  for  the  acquisition  and  use  of  weapons  system 
technical  data  for  contractually  implementing  CALS  requirements  in  weapons  system 
and  related  major  equipment  procurements,  its  purpose  is  to  assist  Acquisition 
Managers  in  transitioning  from  paper-intensive  processes  to  digital  data  delivery  and 
access.  It  also  supports  the  structuring  of  contract  requirements  to  achieve  integration 
of  automated  capabilities  for  design,  manufacturing,  and  logistics  support. 

This  handbook  describes  functional  requirements  and  technical  standards  applicable  to 
ail  programs  for  acquisition  and  support  of  weapons  systems  and  related  major 
equipment  items  to  which  Department  of  Defense  Directive  (DoDD)  5000.1  or 
Department  of  Defense  Instruction  (DoDI)  5000.2  apply.  It  also  is  applicable  for 
systems  and  items  for  which  the  acquisition  of  technical  data  in  digital  form  is  required 
in  accordance  with  MlL-STD-1840,  MlL-STD-1388-1/2,  and  supporting  military 
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specifications.  This  handbook  aJso  addresses  those  specific  functionaJ  capabilities 
requiring  integration  by  the  contractor  to  support  weapons  system  acquisition.  The 
scope  of  this  handbook  continues  to  increase  as  CALS  strategies  are  refined, 
metiX>dologies  for  implementation  are  developed,  and  r>ew  material  for  ir^usion  is 
received  from  Govemmerrt  and  industry. 

A-3.2^  CALS  Intent 

Requirements  issued  through  the  Federal  Acquisition  Regulations  (FARs)  on  3  October 
1989  and  a  DoO  FAR  Supplement  states  that  an  Acquisition  Manager  must  describe 
the  extent  of  CALS  implementation  in  approved  weapons  system  acquisition  plans. 
Policy  guidartce  issued  by  DoO  requires  that  plans  for  new  weapons  systems  and 
related  ms^or  equipment  items  irKlude  use  of  the  CALS  standards.  This  handbook 
provides  detailed  information  on  the  application  of  these  CALS  requirements  to 
weapons  system  and  major  equipment  procurements.  The  use  of  MIL*HDBK*59,  which 
provides  information  and  guidance  to  personnel  responsible  for  the  acquisition  and  use 
of  weapons  system  technical  data,  is  the  CALS  implementation  specification  for  digital 
data  acquisition.  The  MIL-HOBK-59  purpose  is  to  assist  in  the  transition  from 
paper-intensive  processes  to  digital  data  delivery  artd  access. 

A-3,3,3  Relevance 

A  primary  CALS  thrust  is  automation  and  integration  of  the  gerteration,  delivery,  and 
use  of  weapons  system  technical  support  data  over  the  weapons  systems  life  cycle. 
This  data  includes,  among  other  things,  all  tfie  technical  support  information  provided 
and  generated  by  the  ILS  and  LSA  process,  engineer  drawings  and  product  data  used 
in  design  and  manufacturing,  and  technical  manuals  primarily  used  to  support  weapon 
systems. 

A-3  J  MIL-M*29532(EC),  Master  Ubrary  Data  Elements  for  Technical  Publications 
A-3^.1  Scope  and  Purpose 

This  specification  provides  a  uniform  set  of  data  elements  necessary  to  track  and 
control  information  in  Navy  technical  publications  at  the  master  library  level.  It  provides 
a  schema  to  index  technical  publications  and  to  interchange  indexed  technical 
publications  among  contractors.  Navy  technical  data  repositories,  and  the  Navy  user 
community.  This  specification  is  appficabie  to  technical  publications,  which  have  either 
been  converted  to  digital  format  through  scanning  of  existing  hard  copy  publications  or 
created  directly  on  an  automated  document  processing  system  (word  processor  or 
authoring  system).  This  specification  defines  a  logical  file  structure  that  will  permit 
interchange  by  magnetic  ta^,  diskette,  or  optical  disk  media  The  basic  requirement  is 
that  the  interchange  medium  support  a  file  structure.  Presently,  MIL-STD-1840  is 
limited  to  interchange  by  magnetic  tape. 

U-ZJ3J2  CALS  Intent 

Acquisition  Managers  should  seek  improved  methods  and  procedures  for  indexing, 
tracking,  and  controlling  information  relating  to  technical  manuals.  This  indexing  is 
necessary  for  access  to  appropriate  page  images  without  requiring  a  sequential  visual 
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search  from  the  beginning  of  the  file.  Other  computer-sensible  encoding  techniques, 
such  as  SGML,  can  be  considered  self-indexed  and  do  not  require  a  separate  index. 

A-3.3,3  Relevance  to  Technical  Manuals 

The  indexing  methods  described  in  MIL-M-29532(EC)  provide  a  way  of  controlling 
previously  unindexed  digital  files  of  technical  publications  and  may  be  applied  to 
technical  manuals  that  have  been  encoded  as  digital  image  files,  often  in  raster  format 
via  scanning  of  existing  documents.  Other  computer-sensible  encoding  techniques, 
such  as  SGML,  can  be  considered  seif  indexed,  but  this  indexing  provides  a  concise 
index  for  the  interchange  of  technical  information. 

A-3.4  MIL-M-38784,  Manuals,  Technical:  General  Style  and  Format  Requirements 
A>3.4.1  Scope  and  Purpose 

This  specification  prescribes  the  general  style  and  format  requirements  for  preparing  a 
technical  manual.  This  includes  all  technical  documents  that  are  assigned  a  technical 
manual  identification  number  and  are  to  be  controlled  by  a  technical  martual 
management  information  system  or  those  that  are  subject  to  requisition  from  an 
inverrtory  control  point  This  document  provides  for  the  deHvery  of  technical  manuals  in 
both  paper  and  digital  forms.  Three  types  of  techrtical  manuals  are  addressed  by  this 
specification:  Review  Draft  Copy  (ROC);  Preliminary  Technical  Manuals  (PTMs);  and 
Final  Reproducible  Copy  (FRC). 

A-3.4,2  CALS  Intent 

DoOD  5000.2  states  that  technical  data  (including  technical  manuals)  will  be  prepared, 
delivered,  and  used  in  digital  form  unless  It  is  not  cost-effective  for  the  Government  In 
addition,  maximum  use  should  be  made  of  available  contractor-automated  databases. 
MIL-M-38784,  Appendixes  B  and  C,  provide  for  electronic  delivery  of  tecfinicai  manuals 
through  use  of  a  Document  Type  Definition  (DTD)  as  defined  in  MIL-M- 28001. 

A-3.4,3  Relevance  to  Technical  Manuals 

This  standard  addresses  the  style,  format,  quality  assurance  (Q/^  provisions,  and 
preparation  for  delivery  of  that  technical  data  in  accordance  with  both  CALS  and 
non-CALS  standards,  it  supplements  various  technical  corrtent  specifications  (MIL-M- 
15071)  for  certain  types  of  TMs  and  does  not  aiorte  define  delivery  of  any  technical 
data. 

A-3,5  MIL-SPEC-28000  Series 

The  MIL-SPEC-28000  Series  provides  implementation-specific  guidance  for 
preparation  of  textual  and  graphic  data  files  for  technical  publications  cr  product  data 
interchange.  These  standards  are  relevant  for  the  preparation  of  files  that  are  used  in 
MIL-STD-1840  but  can  also  serve  many  other  data  transfer  and  neutral  language 
format  purposes.  This  set  of  standards  defines  how  technical  data  is  to  be  represented 
digitally  in  a  number  of  different  formats. 
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A*3^.1  MIL-O-28000,  Digital  Representation  for  Communication  of  Product  Data: 

IGES  Application  Subsets 

Scop*  and  Purpos* 

MIL>D-28000  defines  a  standard  for  lllustraition  Data  RIe  formats  in  technical 
publications  and  for  product  data  cor^isting  of  engineering  and  system  support  data. 
This  specification  idcfitifies  the  requirements  to  be  met  when  product  definition  data  is 
delivered  in  the  digital  format  of  the  Initial  Graphics  Exchartge  Specification  (IGES)  as 
specified  by  its  American  National  standard,  ANSI  Y14.26M. 

A-3JJ!  MIL-M-28001,  Markup  Requirements  and  Generic  Style  Spedficadon  for 
Electron^  Printed  Output  and  Exchange  of  Text  [Standard  Generalized  Markup 
Language  (SGMLJJ 

Scope  and  Purpose 

MIL>K1-28001  defines  a  standard  for  preparation  of  textual  informalion  for  tectmical 
pubHcatiora.  SGML  is  a  textual  mark-up  language  that  is  formatted  by  various  DTDs 
and  FOSIs  that  define  the  format  and  structure  of  the  textual  output.  DTDs  should 
conform  to  the  appropriate  presentation  specifications  required  for  the  specific  technical 
data  requested.  Additionally,  graphics  csvt  be  incorporated  indirectly  into  the  document 
with  the  use  of  pointers  that  refer  to  the  separate  graphic  files.  Data  prepared  in 
conformance  to  these  requirements  vmII  facilitate  the  automated  storage,  retrieval, 
interchange,  and  processing  of  technical  documents  from  heterogeneous  sources. 

A-3J.3  MIL-R-28002,  Requirements  tor  Raster  Graphics  Representation  in  Binary 
Format 

Scope  and  Purpose 

MIL-R-28002  defines  a  standard  for  representation  of  binary  image  files  for  technical 
publications  that  may  contain  both  textual  and/or  product  illustration  data  There  are 
two  forms  of  raster  data  specified,  formatted  and  unformatted.  Formatted  data  is  the 
only  acceptable  form  for  technical  data  and  may  be  either  tiled  or  untiled.  However, 
tiled  is  the  only  form  acceptable  for  illustration  data  used  in  technical  publications, 
reports,  and  engineer  drawings. 

A-3^.4  MlL-D-28003,  Digital  Representation  tor  Communication  of  Illustration  Data: 
CGM  Application  Prodle 

Scope  and  Purpose 

MiL-D-28003  defines  a  standard  to  be  met  when  two-dimensional  picture  descriptions 
or  illustration  data  that  is  predominantly  vector-oriented  is  delivered  in  the  digital  format 
of  the  Computer  Graphics  Metafile  (CGM). 

A-3  CALS  Intent 

These  specifications  are  the  actual  format  specifications  for  the  digital  data  interchange 
of  textual  and/or  iliustration/engineering  drawing  information.  These  specifications 
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originated  as  ISO  standards  before  the  creation  of  the  CALS  concept,  and  they  provide 
the  basic  forms  of  data  interchange  through  neutral  file  forrnats.  These  basic 
components  will  play  a  large  part  in  more  encompassing  CALS  standards  such  as 
MIL-C-CmS,  which  will  be  the  implementation  of  the  CALS  infrastructure. 

A-3^.6  Relevance 

This  set  of  specifications  defines  how  technical  data,  including  TDPs,  is  to  be 
represented  digitally  in  a  number  of  different  formats.  MIL*R-28002,  raster,  uses 
binary  tiles  and  MIL-0-28003,  CQM,  uses  two-dimensional  vectors  to  represent  a 
scanned  image  ttiat  may  contain  both  textual  and/or  product  illustration  data 
MiL-D-28000,  IGES,  is  unique  because  it  integrates  geometric  location,  nongeometric 
attributes,  text  and  annotation,  and  data  r^ationships  into  a  meaningful  engineering 
drawing  representatioa  MIL-M-28001,  SGML  is  a  textual  mark-up  language  that  can 
be  used  for  text  processing  of  any  drawing  text,  lists,  annotations,  arxl  documentation 
associated  with  a  technical  data  package.  SGML-marked  text  can  be  formatted 
according  to  various  DTDs  and  FOSIs  that  define  the  formal  arKi  structure  of  the  textual 
output  DTDs  should  conform  to  the  appropriate  presentation  spredfications  required  for 
the  specific  technical  data  requested. 

A-3.6  MIL-STD-100,  Engineering  Drawing  Practices 

A-3.6.1  Scope  and  Purpose 

This  standard  prescribes  general  requiremertts  for  the  preparation  and  revision  of 
engineering  drawings  and  associated  lists  prepared  by  or  for  the  departments  and 
agencies  of  the  DoD.  This  standard  provides  all  the  information  necessary  for 
engineering  drawings  to  be  created  and  revised  according  to  standard  procedures  and 
practices.  This  standard  provides: 

•  Standard  dravring  practices  for  preparation  of  engineering  drawings  and 
drawing  format  materials 

•  Requirements  for  drawings  derived  from  or  maintained  by  Computer  Aided 
Design  (CAD) 

•  Definitions  and  examples  of  types  of  engineering  drawings  to  be  prepared  for 
the  DoD 

•  Procedures  for  the  creation  of  titles  for  engineering  drawings, 

•  Numbering,  coding,  and  identification  procedures  for  engineering  drawings, 
associated  lists,  and  documents  referenced  on  these  engineering  drawing  and 
associated  lists 

•  Locations  for  marking  an  engineering  drawing 

•  Requirements  for  preparation  of  associated  lists 

•  Methods  for  revision  of  engineering  drawings  and  methods  for  recording  of  such 
revisions. 
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A-3.62  CALS  intent 


This  document  was  created  to  standardize  the  presentation  format  of  engineering 
drawings  to  be  used  throughout  the  OoO.  Either  paper  or  digital  format  engineering 
drawings  will  contiruje  to  be  the  most  proper  way  to  disclose,  by  means  of  pictorial  or 
textural  presentations,  the  physical  requirements  of  an  end-pr^ucL  This  being  the 
case,  CALS  standards  and  the  Integrated  Weapon  Systems  Data  Base  (IWSDB) 
concept  will  rely  on  engineering  drawings  to  relay  those  end-item  physical 
requirements.  Other  information  defined  by  MIL-STD-100  for  engineering  drawings, 
such  as  functional  and  manufacturing  requirements  and  associated  parts  lists,  has 
begun,  in  the  modem  CALS  terminology,  to  be  included  in  electronic  engirteering 
drawings  through  product  definition  vehides  like  IGES  (MiL-D-28000)  and  POES 
(MIL-P-26004). 

A-3^  J  Relevance  to  Technical  Data  Packages 

This  standard  win  continue  to  define  the  standard  presentation  format  for  all  DoD 
engineering  drawings  and  associated  lists  in  paper  or  digital  format  Since  TOPs 
include  engineering  drawings  as  one  of  its  components,  this  standard  directly  affects 
the  presentation  of  the  TOPs  drawing  and  graphic  elements. 

A-3.7  MIL-STD-1388-1A,  Logistic  Support  Analysis 

A-3.7.1  Scope  and  Purpose 

This  standard  provides  general  requirements  and  task  descriptions  governing 
performance  of  Logistic  Support  Analysis  (LSA)  during  the  life  cycle  of  systems  and 
equipment  This  standard  contains  rationale  for  the  selection  and  tailoring  of  the  LSA 
tasks  required  to  meet  program  objectives  in  a  cost-effective  manner. 

A-3.7^  CALS  Intent 

This  standard  implements  the  LSA  guidelines  and  requirements  established  by  DoDI 
5000.2,  Major  Sy^em  Acquisition  Procedures.  Maximum  use  shall  be  made  of  digital 
data  products.  All  newly  required  LSAR  data  shall  be  in  conformance  to 
MIL-STD-1388-2B. 

A-3.7,3  Relevance 

The  requirements  of  this  standard  are  applicable  to  new  system/equipment  acquisition 
programs,  msqor  modification  programs,  and  applicable  research  and  development 
projects.  The  goal  of  this  standard  is  a  single,  uniform  approach  by  the  Military 
Services  for  conducting  those  activities  necessary  to  cause  supportabiiity 
requirements  to  be  an  integral  part  of  system  requirements  and  design,  (b)  define 
support  requirements  that  are  optimally  related  to  the  design  and  to  each  other,  (c) 
define  the  required  support  during  the  operational  phase,  and  (d)  prepare  attendant 
data  products. 
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A>3J  MIL-STD>1388-2A  &  B,  DoD  Requirements  for  a  Logistic  Support  Analysis 
Record 

A-3.8.1  Scop*  and  Purpos* 

This  standard  prescribes  the  data  element  definitions  (OED).  data  field  lengths,  and 
formats  for  LSAR  data.  It  identifies  the  LSAR  reports  that  are  generated  from  the 
LSAR  data  and  identifies  the  LSAR  relational  tables  arKi  AOP  ^>ecifications  for 
transmittal  and  delivery  of  automated  LSAR  data. 

A-3.8.2  CALS  intent 

MIL‘STD-1388-2B  specifically  provides  for  a  distal,  relational  database  to  ma)dmize  the 
use  of  bitegrated  data  systems  tied  to  engineering,  manufacturing,  and  product  support 
databases  as  sources  of  LSA  documentation.  This  standard  is  directed  toward 
improving  the  cost-effectiveness  of  generation,  maintenance,  acquisition,  and  use  of 
the  technical  data  required  to  support  an  ILS  program.  The  LSAR  is  intentiorudly 
structured  to  accommodate  the  maximum  range  of  data  potentifidly  required  by  all 
services  and  all  ILS  element  functional  areas.  C/U.S  requiremertts  for  LSAR  will  be  met 
through  the  use  of  an  approved  LSAR  AOP  system. 

A*3.8.3  Relevance 

This  standard  allows  for  delivery  of  LSAR  data  in  manual  or  automated  mode  ar^  on¬ 
line  access  to  LSAR  data  as  specified  by  the  requiring  authority.  It  does  not  prescribe 
which  AOP  software  must  be  used  to  process  LSAR  data.  The  minimum  AOP  design 
requirements  that  must  be  adhered  to  for  industry-developed  LSAR  AOP  systems  are 
described  in  MiL'STO-1388-2,  General  Requirements. 

A-3.9  MIL-STD-1 840,  Automated  Interchange  of  Technicsd  information 

A-3.9.1  Scope  and  Purpose 

MIL-STO-1840  provides  an  overall  instructional  approach  to  the  use  of  the 
MIL'SPEC-28000  Series  for  technical  data  (including  ILS  dats^  interchange.  The 
purpose  of  this  document  is  to  standardize  the  digital  interface  for  the  exchange  of 
digital  information.  The  standard  currently  addresses  the  interface  of  computer 
tedinologies  Oiat  are  automating  the  creation,  storage,  retrieval,  and  delivery  of  ILS 
data,  engineering  drawings,  and  other  technical  information.  MIL-STD-1 840  defines 
standard  file  sets  and  formats,  data  file  representation  standards,  header  record 
formats,  and  file-naming  conventions  for  the  transfer  of  technical  informatioa  Such 
information  includes  training  and  maintenance  manuals  with  their  associated 
illustrations;  product  definition  data,  such  as  engineering  drawings  and  spedficatiorts; 
and  the  evolving  product  data  concept  that  provides  for  transfer  and  archival  storage  of 
product  information  in  a  form  directly  usable  by  computer  applications. 

A-3.9.2  CALS  intent 

With  the  overall  goal  of  CALS  to  migrate  toward  a  paperless  environment, 
MIL-STD-1 840  orchestrates  the  use  of  the  MiL-SPEC-28000  Series  and  is  one  of  the 
fundamental  basic  standards  for  digital  data  interchange  of  textural  and/or 
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illustralion/engineering  drawing  informalion.  Once  the  acquisition  of  the  data  has  been 
resolved,  It  is  MIL-STD-1B40  that  defines  the  process  for  the  way  the  technical  data  is 
to  be  transferred.  As  with  the  implementalion  of  the  Contractor  Integrated  Technical 
Information  Sen/ice  (CmS),  the  potential  exists  for  substantial  quality  improvements 
and  reductions  in  acquisition  and  support  costs  through  use  of  the  CALS  standards  due 
to  the  elimination  of  duplicate,  manual,  error-prone  processes.  This  startdard  in 
cor^unction  with  the  MIL-SPEC-28000  Series  will  produce  improved  responsiveness  of 
the  industrial  base  by  development  of  integrated  design  and  manufacturing  capabilities 
and  by  irtdustry  networks  to  construct  and  support  systems  and  equipment  based  on 
digital  product  descriptions. 

A-3.9.3  Relevance 

This  standard  defines  how  technical  information,  including  TOP  elements  and  possibly 
technical  manuals,  is  to  be  represented  digitally  in  a  number  of  different  formats  that 
are  to  be  used  for  digital  data  interchange.  MtL-STD-1840  specifies  media  types  and 
then  refers  to  the  MIL-SPEC-28000  Series  for  detailed  format  specifications. 

A-3.10  ^/aL‘^~3^000,  Technical  Data  Packages 

A-3.10.1  Scope  and  Purpose 

This  specification  prescribes  the  requirements  for  preparing  a  TCP  composed  of  one  or 
more  TOP  elements  and  related  TOP  matfiagement  data  products.  This  includes,  but  is 
not  limited  to,  TOPS  prepared  for  use  in  development,  procurement,  production, 
installation,  maintenance,  provisionirtg,  transportation,  configuration  management  and 
mobilization.  Selection  of  the  TOP  elements  and  TOP  data  management  products  must 
be  based  on  the  degree  of  design  disclosure  required  to  support  the  acquisition  and 
life-cycle  support  strategies  for  the  product  being  documented. 

This  specification  covers  the  following  elements  of  TOPs  and  TOP  management  data 
products; 

TOP  Bements: 

•  Conceptual  design  drawings  and  associated  lists 

•  Oevelopmental  design  drawings  and  associated  lists 

•  Product  drawings  and  associated  lists 

•  Commercial  drawings  and  associated  lists 

•  Special  inspection  equipment  (SIE)  drawings  and  associated  lists 

•  SIE  operating  instru^tiO'is 

•  SIE  calibration  procedures 

•  SIE  descriptive  documentation 

•  Special  tooling  drawings  and  associated  lists 

•  Spedficafions 

•  Preservation,  packaging,  packing,  and  marking  data 

•  Software  documentation 

•  Test  requirements  documents 

•  TOP  document  list 

•  Certification  data  sheet 


TOP  Management  Data  Products: 


•  Source  control  drawing  approval  request 

•  Drawing  number  assignment  report 

•  Proposed  critical  manufacturing  process  description 

•  TOP  quality  control  program  plan 

•  TOP  validation  report 

•  Quality  engineering  planning  list 

•  Engineering  release  record 

A-3.10^  CALS  Intent 

MIL-T-31000  provides  CALS-implementation  guidance  for  acquiring  data  products  in 
digital  form  by  referencing  OoO  Policy  and  the  CALS  Program  implementation  Guide. 
DoD  Directive  5000.2  states  that  technical  data  (including  engineering  drawings)  win  be 
prepared,  defivered,  and  used  in  digital  form  unless  it  is  not  cost-effective  for  the 
Government  in  addition,  maximum  use  should  be  made  of  available  contractor- 
automated  databases.  The  use  of  MIL-HDBK-59.  which  provides  information  and 
guidance  to  personnel  responsible  for  the  acquisition  and  use  of  defense  system 
technical  data,  is  called  for  in  MIL-T-31000  as  ttie  CALS-implementation  handbook  for 
digital  data  delivery  and  access. 

A-3.10^  Relevance  to  Technical  Data  Padcages 

See  A-3.10.1.  Scope  and  Purpose. 
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APPENDIX  B 


PRODUCT  DATA 


SECOND  EDITION 


30  JunBl983 


Prepared  by; 

CALS  Reeource  and 
Implementation  Cooperative  (RIC) 


Prepared  for. 

Navy  CALS  Acquisition/ 
implementation  Group 


B-I.O  inteliigent  (Product)  Data 


Product  data  are  the  totality  of  data  elemerrts  required  to  completely  defirM  a  product 
throughout  its  entire  life  cycle.  Engineering  drawings  make  up  a  very  smafi  portion  of 
product  data  and  provide  only  the  human  interpretable  information  for  a  system. 
Standards  are  currently  being  developed  to  define  more  completely  this  form  of  product 
data 

•  VHSIC  hardware  description  language 

•  Electronic  Design  Interchange  Format  (EDIF) 

•  Native  CAD  format 

•  Gerber  data 

B>2.0  Advantages  and  Disadvantages 

Product  data  are  the  most  compreher«ive  form  of  digital  data  Product  data  contain  all 
information  needed  to  completely  describe  a  product,  and  a  large  portion  of  this 
information  can  be  directly  interpreted  by  a  computer.  This  capability  provides  several 
advantages.  Product  data  allow  the  simulation  of  systems  modifications  prior  to 
implementation  and  evaluation  of  form,  fit  and  function  performance  of  components. 
In  addition,  product  data,  with  its  inherent  intelligence,  can  be  used  to  drive 
manufacturing  processes.  A  distinct  disadvantage  of  product  data  is  that  this 
intelligence  is  not  transferable  to  other  data  deliverable  options.  The  creation  of 
engineering  drawings  invokes  a  presentation  format  in  which  much,  if  not  all,  the 
intelligence  of  the  product  data  is  lost  In  addition,  product  data  are  more  conceptual 
than  real.  Product  data  are  also  the  most  expensive  data  deliverable  option. 

B-3.0  Life  Cycle  Considerations 

Delivery  of  product  data  is  generally  not  cost  effective  during  the  early  stages  of  a 
weapons  s^em  program's  life  cycle.  The  advantages  of  intelligent  data  are  not  fully 
utilized  earty  in  the  life  cycle  due  to  the  typical  use  of  the  data,  which  is  usually  'View 
only.”  However,  during  the  Engineering  and  Manufacturing  Development  (EMD)  phase, 
intdiigent  product  data  may  be  useful  because  all  other  data  deliverable  options  can  be 
created  from  this  type  of  data  In  addition,  intelligent  data  will  support  design  changes 
and  system  modifications  throughout  the  production  and  deployment  phase  of  a 
weapons  system  program. 

B-4.0  infrastructure 

Product  data  require  a  powerful  computer  environment  with  the  appropriate  CAD 
hardware  and  software  to  invoke  it.  The  environment  created  by  product  data  has  the 
capability  to  produce  all  other  forms  of  digital  and  nondigital  data 

B>5.0  Validation  and  Verification 

Product  data  provide  inherent  means  for  validation  and  verification  because  it  contains 
relationship  iriformation  about  the  various  components  that  make  up  the  product  being 
described.  It  is  envisioned,  and  in  some  cases  a  reality,  that  applications,  such  as 
simulators,  can  be  used  on  the  data  to  not  only  verify  conformance  to  the  digital  data 
standard  but  also  to  validate  the  technical  content  per  contractual  requirements. 


B-6.0  Contract  Language 


In  order  to  invoke  this  data  deliverable  option,  specific  CDRLs  must  be  developed  for 
each  unique  data  format  and  CAO  system  for  which  data  is  required.  The  fdlowing 
sample  CDRLs  specify  Gerber  data,  which  are  useful  in  certain  manufacturing 
environments,  and  also  additional  sample  CDRLs  of  product  data  deliverables.  The 
information  contained  in  these  contract  vehicles  should  be  tailored  to  meet  the 
requirements  of  the  specific  weapons  system  program. 
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APPENDIX  C 


NAVY  INFRASTRUCTURE 
MODERNIZATION  PROGRAMS 

AND 

OTHER  PROGRAMS  UTILIZED 

FOR 

TDPs,  TM,  &  LSA  DATA 


SECOND  EDITION 


30  June  1993 


Prepared  by; 

CALS  Resource  and 
Implementation  Cooperative  (RIC) 


Prepared  for: 

Navy  CALS  Acquisition/ 
Implementation  Group 


C-1.0  The  Navy  infrastaicture  modernization  programs  and  other  programs  utilized  to 
aid  in  the  creation,  management,  and  use  of  technical  data  packages  are: 


•  Computer-Aided  Design  (Second  Acquisition)  (CA02) 

•  Joint  Engineering  Data  Management  Information  and  Control  System 
(JEDMICS) 

•  Navy  Engineering  Drawing  Asset  Locator  System  (NEDALS) 

•  Advanced  Industrial  Management  (AIM) 

•  Advanced  Technical  Information  System  (ATIS). 

C-1.1  CAD2 

CAD-2  is  a  msqor,  shore-based  infrastructure  enhancement  initiative  to  drastically 
improve  and  more  fully  automate  all  design,  development,  and  engineering  activities 
accomplished  by  the  Navy  during  the  acquisition,  production,  and  support  of  military 
defense  systems.  This  CALS  program  involves  computer  hardware  and  software  for 
design,  analysis,  modeling,  simulation,  documentation,  data  transfer,  and  data 
management,  as  well  as  the  necessary  technical  services  for  maximize  utility  of  these 
tools  for  the  Navy. 

The  CAO-2  program  provides  the  necessary  off-the-shelf  equipment,  software,  and 
support  services  to  replace  time  consuming  manual  drafting  and  obsolete 
CAD/CAM/CAE  capabilities  with  modem  computer-assisted  technology.  This  concept 
also  enhances  the  interoperability  capabilities  of  the  engineering  community.  Navy, 
DoD,  and  contractors.  This  system  will  be  employed  to  create,  manage,  and  use 
engineering  analysis  data,  engineering  drawings,  technical  reports,  technical  manuals, 
technical  orders,  bid  packages,  manufacturing  data,  product  models,  and  work 
packages. 

C-1,2  JEDMICS 

JEDMICS  provides  a  standard  digital  system  for  storage,  retrieval,  reproduction,  and 
distribution  of  engineering  drawings  and  related  technical  data  to  support  defense 
system  maintenance,  reprocurement  of  spares,  engineering,  training,  manufacturing, 
and  logistics  support.  Engineering  Drawing  Print-On-Demand  System  (EDPODS) 
provides  stand-alone  production  printing  capability  from  a  JEDMICS  database. 

C-1.3  NEDALS 

NEDALS  is  an  automated  index  and  ordering  system  for  all  Navy-engineering  drawings. 
It  provides  continuous  on-line  access  to  Navy  engineering  drawing  information. 
NEDALS  is  the  point  of  entry  for  Navy  engineering  drawing  information  to  transfer  to 
the  DoD  Military  Engineering  Data  Asset  Locator  System  (MEDALS). 
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C-1.4  AIM 


AIM  is  a  major.  Naval  shipyard  initiative  to  change  the  functional  process  for  ship 
maintenance  and  repair  management  by  improving  the  shipyard's  ability  to  plan, 
estimate,  schedule,  and  execute  work.  The  initiative  will  modify  and  streamline  current 
ship  alterations  and  repair  processes  by  installing  automated  tools  to  access  and  use 
digital  technical  information.  The  initiative  will  also  integrate  these  automated  tools  with 
other  automated  systems  and  ultimately  reconfigure  shipyard  processes  and 
organizations  to  capitalize  on  this  integration.  There  are  two  modules  within  AIM,  the 
ATIS  module  and  the  Advanced  Planning  and  Packaging  Support  (APPS)  module.  The 
ATIS  module  is  designed  to  place  current  and  accurate  digital  tecnnicai  data  in  the 
hands  of  Naval  shipyard  personnel  by  serving  as  the  Navy-standard  user  presentation 
system  for  displaying  digital  logistic  technical  data.  The  APPS  module  will  create  wcrk 
packages  from  the  technical  information  in  ATIS  to  package  and  manage  shipyard 
work. 

C-1.5  ATIS 

ATIS  is  a  delivery  system  designed  to  provide  shipboard  and  shipyard  users  current 
and  accurate  digital  technical  data  In  the  shipyard  environment,  ATIS  allows  engineers 
to  access  technical  documentation  [drawings  or  technical  manuals  identified  through 
Ship  Configuration  and  Logistics  Support  Information  System  (SCLSIS)]  to  retrieve  data 
from  a  digital  repository  (JEDMICS)  or  to  create  technical  information  files  (TIFs) 
containing  repair/planning  data.  TIFs  will  then  be  used  to  produce  task  sheets  for 
shipyard  industrial  personnel. 

The  shipboard  ATIS  will  provide  a  standard  technical  documentation  retrieval  method 
for  ship's  company  at  a  single  work  station.  The  ATIS  platform  will  use  Shipboard 
Non-technicai  AOP  Program  (SNAP)  data  as  a  source  for  identifying  required 
documentation.  Documentation  to  be  available  in  ATIS  includes  engineering  drawings, 
technical  manuals,  preventive  maintenance  data,  ano  engineering  operating  and 
sequencing  data  ATIS  is  also  used  by  other  Navy/Marine  Corps  system  commands  on 
similar  uses  and  technical  data  display  purposes. 

C-1.6  Document  Type  Definition  (DTD) 

A  DTD  defines  the  rules  of  a  document's  structure  and  the  relationships  among  the 
structural  elements  (i.e.  chapters  contain  sections  that  contain  paragraphs  etc.).  Rules 
are  determined  by  an  application  that  apply  SGML  to  the  markup  ot  documents  of  a 
particular  type.  A  DTD  includes  a  formal  specification,  expressed  in  a  document  type 
declaration,  of  the  element  types,  element  relationships  and  attributes,  and  references 
that  could  be  represented  by  markup.  It,  thereby,  defines  the  vocabulary  of  the  markup 
for  which  SGML  defines  the  syntax. 

C-1.7  Output  Specification  (OS)  and  Formatting  Output  Specification  Instance 
(FOSI) 

An  OS  is  a  finite  set  of  style  characteristics  to  convey  formatting  intent  for  interchange 
of  technical  publications  coupled  with  a  mechanism  for  binding  the  style  characteristics 
to  logical  elements  in  an  SGML  document  type  declaration.  The  OS  provides  a  set  of 
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formatting  characteristic  values  used  to  rigorously  describe  composition  processing 
functions  to  be  performed  on  the  elements  of  a  text  document  to  provide  the  format 
and  style  required  by  MIL-M-38748.  The  OS  uses  the  syntax  of  an  SGML  document 
type  declaration. 

A  FOSI  is  an  element  of  the  OS  that  assigns  values  to  the  style  characteristics  for  a 
particular  document  type  declaration.  The  FOSI  uses  the  syntax  of  an  SGML 
document  instance.  The  FOSI  portions  can  be  tailored  or  modified  to  satisfy  the  format 
and  style  requirements  cited  in  the  governing  specification  or  in  the  contract.  An 
objective  of  the  FOSI  is  to  rigorously  define  the  format  and  style  of  the  document 
produced  from  the  SGML-tagged  text.  Together  with  the  markup  tags  specified  in 
MIL-M-28001,  the  FOSI  provides  a  basic  vocabulary  from  which  changes  in  output 
processing  statements  (macros)  can  be  constructed.  FOSI  delivered  with  the 
document  must  contain  certain  values  for  characteristics  of  every  context  in  which  the 
tag  has  a  unique  formatting  requirement. 
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C-2.0  The  Navy  infrastructure  modernization  programs  and  other  programs  utilized  to 
aid  in  the  creation,  management  and  use  of  ILS  data  and  LSAR  are; 


•  LOGistics  Planning  And  Requirements  Simplification  (LOGPARS) 

•  Ship  Configuration  and  Logistic  Support  Information  System  (SCLSIS) 

•  Advanced  Industhai  Management  (AIM) 

•  Configuration  and  Logistics  information  Program  (CUP) 

•  Solicitation  Package  Automation  (SPA) 

An  overview  of  these  information  management  infrastructure  programs  is  provided 
below. 

C-2.1  LOGPARS 

LOGPARS  is  a  personal  computer-based  ILS  project  management  expert  system  that 
leads  an  ILS  manager  through  the  thought  process  necessary  to  plan  and  execute  an 
ILS  program.  LOGPARS  incorporates  the  required  policy,  lessons  learned,  and  expert 
experience  to  produce  critical  ILS  program  doaimentation.  The  systematic,  user- 
friendly  approach  LOGPARS  offers  ensures  ail  considerations  are  addressed,  existing 
policy  is  complied  with,  and  the  potential  for  contracting  redundant  information  is 
eliminated.  Products  produced  by  LOGPARS  include  the  ILS  Statement  of  Work 
(SOW)  and  accompanying  CORL,  an  ILS  milestone  schedule,  and  a  baseline  warranty 
clause. 

C<2^  SCLSIS 

SCLSIS  is  the  configuration  status  accounting  system  for  shipboard  hardware.  It 
maintains  the  master  file  of  hardware  configure  item  identity  and  the  identity  of 
technical  and  logistics  products  that  are  applicable  to  the  hardware  items.  SCLSIS 
information  will  be  used  to  define  what  digital  products  need  to  be  assembled  into 
packages  for  particular  functions.  Such  packaging  files  will  be  automatically  updated 
via  SCLSIS  as  configuration  changes  are  made  to  any  ship  in  the  class. 

C-2.3  AIM 

AIM  is  a  major  Naval  shipyard  initiative  to  change  the  functional  process  for  ship 
maintenance  and  repair  management  by  improving  the  shipyard's  ability  to  plan, 
estimate,  and  schedule  work.  There  are  two  modules  within  AIM.  The  Advanced 
Technical  Information  System  (ATIS)  module  is  designed  to  place  current  accurate 
digital  technical  data  in  the  hands  of  Naval  shipyard  personnel.  The  Advanced 
Planning  and  Packaging  Support  (APPS)  module  ''  ill  create  work  packages  from  the 
technical  information  in  ATIS  to  package  and  manage  shipyard  work. 

C-2.4  CUP 

CLIP  is  similar  to  SCLSIS,  as  it  is  also  a  configuration  accounting  system  program. 
CLIP  supports  life-cycle  baseline  management  for  both  engineering  documentation  and 
hardware.  It  will  also  track  multiple  baselines  and  will  establish  a  functional  baseline 
based  on  Hierarchical  Structure  Code  by  Class.  CLIP  will  also  track  documents  and 
part  number  information.  Engineering  documents,  part  numbers,  and  technical  manuals 
are  cross-referenced  and  accessible  to  the  user  from  a  single  work  station.  It  allows 
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locai  request  and  retrieval  of  raster  images  when  "primary*  repositories  are  not 
available.  It  complies  with  MIL-R-28002. 

C-2.5  SPA 


SPA  stores  CALS-compliant  digital  solicitation  packages  (forms,  clauses,  technical 
specifications,  and  drawings)  for  prirtt-on-demand  output  at  the  two  Navy  inventory 
control  points  (ASO  and  SPCC). 
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C-3.0  The  Navy  infrastaicture  modernization  programs  utilized  to  aid  in  the  creation, 
management,  and  use  of  technical  manuals  are: 

•  Automated  Logistics  Publishing  System  (ALPS) 

•  Technical  Manual  Print-On- Demand  System  (TMPODS) 

•  Advanced  Technical  Information  SystenrVIrrteractive  Bectronic  Technical 
Manuals  (ATIS/IETM) 

C-3.1  ALPS 

ALPS  is  a  CALS-compliant  (ASCII/SGML)  publishing  system  for  the  acceptance, 
verification,  creation,  and  updating  of  technical  manuals  and  other  Navy  documentation 
delivered  from  hardware  contractors  or  authored  in-house.  Automated  Document 
Management  and  Publishing  System  (ADMAPS)  is  the  fourth  band  (NAVSUP  band)  of 
the  CAD2  contract,  which  has  been  identified  for  integrated  pubiisNng  systems.  In 
addition  to  incorporating  ALPS  functionality,  this  contract  will  provide  to  Navy 
Publishing  and  Printing  Service  (NPPS)  the  additional  capability  to  'bridge*  the  other 
CAD2  contract  bands  with  JEDMICS  by  allowing  for  the  conversion  to  and  from  the 
vector  format  of  CAD2  and  the  raster  format  of  JEDMICS. 

C-3.2  TMPODS 

TMPODS  provides  a  standard  digital  system  for  administration,  storage,  retrieval, 
reproduction,  conversion  of  legacy  technical  data,  output  on  demand  (paper/digital), 
and  distribution  of  CALS-compliant  digital  files  (SGML/raster)  for  Navy  techniciy 
manuals.  TMPODS  will  use  current  supply  systems  and  procedures  to  interface  with 
SYSCOMS  and  end  users. 

C-3.3  ATIS/IETM 

ATIS  is  a  delivery  system  designed  to  place  current  and  accurate  digital  technical  data 
into  user  (shipyard  and  shipboard)  hands.  In  the  shipyard  environment,  ATIS  is  an  AIM 
module  that  allows  engineers  to  access  component  technical  documentation  {drawings 
or  technical  manuals  identified  through  Ship  Configuration  and  Logistics  Support 
Information  System  (SCLSIS)},  retrieve  it  from  a  digital  repository  (JEDMICS).  and 
create  technical  information  files  (TIFs)  containing  relevant  repalr/planning  data.  TIFs 
will  be  used  by  the  APPS  module  of  AIM  to  produce  task  sheets  for  shipyard  industriai 
personnel. 

The  shipboard  ATIS  is  intended  to  provide  a  standard  retrieval  method  for  technical 
documentation  for  ship's  company  at  a  single  workstation.  The  ATIS  platform  will  use 
Shipboard  Nontechnical  Automated  Data  Processing  Program  (SNAP)  data  as  a  source 
for  identifying  required  documentation.  The  sailor  then  retrieves  data  from  optical 
platters.  Documentation  to  be  available  in  ATIS  includes  engineering  drawings, 
technical  manuals,  Planned  Maintenance  System  (PMS)  data,  and  Engineering 
Operating  and  Sequencing  System  (EOSS)  data 

lETM  is  an  irrteractive  display  system  using  optimally  packaged  and  formatted  technical 
information  for  screen  presentation  of  maintenance  and  diagnostics  information. 
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